第 1 章，方法

Chapter 1, The Method

第 1 章介绍了这一关键思想：要想成功，你必须同时设计系统和构建系统的项目。这两种设计对于最终的成功都至关重要。没有架构就无法设计项目，设计一个无法构建的系统是没有意义的。

Chapter 1 introduces this key idea: To succeed, you must design both the system and the project to build it. Both designs are essential for eventual success. You cannot design the project without the architecture, and it is pointless to design a system that you cannot build.

第一部分：系统设计

Part 1: System Design

第二部分：项目设计

Part II: Project Design

附录

Appendices

注册您的产品

Register Your Product

在 InformIT 网站上注册您的Righting Software 副本，以便在更新和/或更正可用时方便地访问它们。要开始注册过程，请转到informit.com/register并登录或创建帐户。输入产品 ISBN (9780136524038) 并单击提交。在“已注册产品”选项卡上查找此产品旁边的“访问奖励内容”链接，然后单击该链接访问任何可用的奖励材料。如果您希望收到有关新版本和更新的独家优惠通知，请选中复选框以接收我们的电子邮件。

Register your copy of Righting Software on the InformIT site for convenient access to updates and/or corrections as they become available. To start the registration process, go to informit.com/register and log in or create an account. Enter the product ISBN (9780136524038) and click Submit. Look on the Registered Products tab for an Access Bonus Content link next to this product, and follow that link to access any available bonus materials. If you would like to be notified of exclusive offers on new editions and updates, please check the box to receive email from us.

设计验证

Design Validation

设计验证至关重要，因为组织不应冒险让团队开始开发不充分的架构或开发组织无法承担的系统。该方法支持并实现这一关键任务，使架构师能够有合理的信心断言所提出的设计是足够的；也就是说，设计满足两个关键目标。首先，设计必须满足客户要求。其次，设计必须解决组织或团队的能力和约束。

Design validation is critical because an organization should not risk having a team start developing against an inadequate architecture or developing a system the organization cannot afford to build. The Method supports and enables this critical task, allowing the architect to assert with reasonable confidence that the proposed design is adequate; that is, the design fulfills two key objectives. First, the design must address the customer requirements. Second, the design must address the organization or the team capabilities and constraints.

一旦开始编码，由于成本和进度问题，更改架构通常是不可接受的。实际上，这意味着，如果没有系统设计验证，就有可能锁定一个不完美的架构，最坏的情况是，锁定一个怪物。组织将不得不在接下来的几年和几个版本中尝试使用最终的系统，直到下一次大规模重写。设计不良的软件系统可能会严重损害企业，使其失去响应商业机会的能力，甚至可能因软件维护成本不断上升而导致财务崩溃。

Once the coding starts, changing the architecture is often unacceptable due to the cost and schedule implications. In practice, this means that without system design validation, there is risk of locking in, at best, an imperfect architecture and, at worst, a monstrosity. The organization will have to try to live with the resulting system for the next few years and several versions until the next big rewrite. A poorly designed software system may seriously damage the business, depriving it of the ability to respond to business opportunities, and may even financially ruin it with escalating software maintenance costs.

尽早验证设计至关重要。例如，在工作开始三年后发现某个特定想法或整个架构是错误的，这在智力上很有趣，但没有实际价值。理想情况下，在项目开始一周后，您必须知道架构是否站得住脚（或站不住脚）。任何更长时间都存在以可疑架构开始开发的风险。以下章节精确描述了如何验证系统设计。

Early validation of the design is imperative. For example, discovering three years after the work started that a particular idea or the whole architecture was wrong is intellectually interesting but of no practical value. Ideally, one week into the project, you must know if the architecture is going to hold water (or not). Anything longer runs the risk of commencing development with a questionable architecture. The following chapters describe precisely how to validate a system design.

请注意，我这里指的是系统设计、架构，而不是系统的详细设计。详细设计为架构中的每个组件生成关键的实现工件，例如接口、类层次结构和数据契约。详细设计需要更长的时间来生成，可以在项目执行期间完成，并且可能会随着系统的构建或发展而发生变化。

Note that I am referring here to the system design, the architecture, not the detailed design of the system. Detailed design produces for each component in the architecture the key implementation artifacts, such as interfaces, class hierarchies, and data contracts. Detailed design takes longer to produce, can be done during the project execution, and may change as the system is constructed or evolved.

同样，您必须验证您的项目设计。项目中期耗尽时间或超出预算（或两者兼而有之）是绝对不可接受的。未能履行承诺将限制您的职业生涯。您必须主动验证您的项目设计，以确保手头的团队能够交付项目。

Similarly, you must validate your project design. Running out of time or running over budget (or both) mid-project is simply unacceptable. Failing to meet your commitments will limit your career. You must proactively validate your project design to ensure that the team at hand can deliver the project.

除了提供架构和项目计划之外，该方法的目标是消除设计对项目的风险。任何项目都不应该因为架构过于复杂而无法由开发人员构建和维护而失败。该方法可以高效、有效地发现架构，并且只需很短的时间。同样的好处也适用于项目设计。任何项目都不应该因为从一开始就没有足够的时间或资源而失败。本书向您展示了如何准确计算项目工期和成本以及如何做出明智的决策。

In addition to providing the architecture and project plans, the objective of The Method is to remove design as a risk to the project. No project should fail because the architecture was too complex for developers to build and maintain. The Method discovers the architecture efficiently and effectively and does so in a short period of time. The same benefit applies to project design. No project should fail because it did not have enough time or resources from the start. This book shows you how to accurately calculate the project duration and costs and how to drive educated decisions.

时间紧迫

Time Crunch

使用该方法，您只需几天时间（通常为三到五天）即可完成整个系统设计，项目设计所需的时间也差不多。考虑到这项工作的崇高目标，即为新系统制定系统架构和项目计划，持续时间可能显得太短。典型的业务系统每隔几年才会有一次新设计的选择。为什么不花 10 天时间在架构上呢？与多年的系统寿命相比，多花五天甚至不算什么。但是，增加设计时间通常不会改善结果，甚至可能有害。

Using The Method, you can produce an entire system design in mere days, typically in three to five days, with project design taking similar time. Given the lofty goals of the effort, namely, producing the system architecture and the project plans for a new system, the duration may look too short. Typical business systems get the option of a new design only every few years. Why not spend 10 days on the architecture? Measured against a system lifetime of years, five additional days are not even a rounding error. However, adding design time often does not improve the result and can even be detrimental.

大多数工作环境的时间管理效率极低，这主要是人性使然。时间紧迫迫使你（和其他相关人员）集中精力，确定优先事项，并完成设计。你应该迅速果断地完成方法。

Most work environments have horrendously inefficient time management, mostly due to human nature. A time crunch forces you (and the others involved) to focus, to prioritize, and to produce the design. You should go through The Method quickly and decisively.

一般来说，设计并不耗时（与实施相反）。建筑师按小时收费，通常最多只花一两个星期来设计一栋房子。根据建筑师的设计建造一栋房子可能需要与承包商一起痛苦地工作两到三年，但建筑师很快就完成了建筑设计。

In general, design is not time-consuming (as opposed to implementation). Building architects charge hourly and often work only a week or two at most designing a house. Constructing a house from the architect’s design might take an agonizing two to three years of working with contractors, and yet the architect did not take long to produce the architecture.

时间紧迫也有助于避免设计过度。帕金森定律²指出，工作总是会扩展到填满分配的时间。如果给 10 天时间来完成一个可以在 5 天内完成的设计，架构师很可能会花 10 天时间进行设计。架构师会利用额外的时间来设计一些无关紧要的方面，这些方面只会增加复杂性，从而不成比例地增加未来几年的实施和维护成本。限制设计时间会迫使你制作出足够好的设计。

The time crunch also helps avoid design gold plating. Parkinson’s law² states that work always expands to fill the allotted time. Given 10 days to complete a design that could be completed in five days, the architect will likely work on the design for 10 days. The architect will use the extra time to design frivolous aspects that add nothing but complexity, disproportionally increasing the cost of implementation and maintenance for years to come. Limiting the design time forces you to produce a good-enough design.

2. Cyril N. Parkinson，《帕金森定律》，《经济学人》 （1955 年 11 月 19 日）。

2. Cyril N. Parkinson, “Parkinson’s Law,” The Economist (November 19, 1955).

消除分析瘫痪

Eliminating Analysis-Paralysis

分析瘫痪是一种困境，当某个人（或某个团体）原本很有能力、聪明甚至勤奋（大多数软件架构师都是如此）却陷入了看似无休止的分析、设计、新发现和更多分析的循环中时，就会发生这种情况。这个人或团体实际上陷入了瘫痪，无法产生任何有成效的成果。

Analysis-paralysis is a predicament that occurs when someone (or a group) who is otherwise capable, clever, and even hardworking (as are most software architects) is stuck in a seemingly endless cycle of analysis, design, new revelations, and back to more analysis. The person or group is effectively paralyzed and precluded from producing any productive outcome.

沟通

Communication

该方法的一个重要优势是能够传达设计理念。一旦参与者熟悉了架构的结构和设计语义，该方法就可以共享设计理念并准确传达设计要求。你可以将设计背后的思维过程传达给团队。你应该分享指导你设计架构的权衡和见解，以明确的方式记录操作假设和由此产生的设计决策。

An important advantage of The Method is in communicating design ideas. Once participants are familiar with the structure of the architecture and the design semantics, The Method enables sharing design ideas and precisely conveying what the design requires. You can communicate the thought process behind the design to the team. You should share the tradeoffs and insights that guided you in the architecture, documenting in an unambiguous way the operational assumptions and the resulting design decisions.

设计意图的这种清晰度和透明度对于架构的生存至关重要。好的设计是经过精心构思、在开发过程中得以生存并最终成为客户机器上的工作位。您必须能够将设计传达给开发人员并确保他们重视设计背后的意图和概念。您必须通过使用评审、检查和指导来执行设计。由于结合了定义良好的服务语义和结构，该方法在这种类型的沟通方面表现出色。

This level of clarity and transparency in design intent is critical for architecture survival. A good design is one that was well conceived, survived through development, and ended up as working bits on customer machines. You must be able to communicate the design to the developers and ensure that they value the intent and the concepts behind the design. You must enforce the design by using reviews, inspection, and mentoring. The Method excels at this type of communication because of the combination of well-defined service semantics and structure.

请放心，如果负责构建系统的开发人员不理解和重视设计，他们就会破坏它。无论设计或代码有多少审查永远无法修复这种混乱。审查的目的应该是尽早发现架构中意想不到的偏差。

Rest assured that if the developers who are tasked with building the system do not understand and value the design, they will butcher it. No amount of design or code review can ever fix that butchery. The purpose of reviews should be to catch the unintended deviation from the architecture as early as possible.

在向项目经理、管理人员或其他利益相关者传达项目计划时，情况也是如此。清晰、明确、可比较的选项是做出明智决策的关键。人们做出错误的决定，往往是因为他们不了解项目，对项目的行为方式有错误的思维模型。通过为项目建立正确的时间、成本和风险模型，架构师可以做出正确的决策。该方法提供了正确的词汇和指标，以便以简单明了的方式与决策者沟通。一旦管理人员了解了项目设计的可能性，他们就会成为其最坚定的拥护者，并坚持以这种方式工作。再多的激烈争论也无法达到一组简单的图表和数字所能达到的效果。此外，项目设计不仅在项目开始时很重要。随着工作的开始，您可以使用项目设计的工具向管理层传达变更的效果和可行性。附录 A讨论了项目跟踪和管理变更。

The same holds true when it is time to communicate the project plan to project managers, managers, or other stakeholders. Clear, unambiguous, comparable options are key to educated decisions. When people make the wrong decisions, it is often because they do not understand the project and have the wrong mental model for how projects behave. By producing the correct models for the project across time, cost, and risk, the architect can enable the right decision. The Method provides the right vocabulary and metrics for communicating with decision makers in a simple and concise way. Once managers are exposed to the possibilities of project design, they will become its greatest advocates and insist on working that way. No amount of passionate arguments can accomplish what a simple set of charts and numbers can. Moreover, project design is important not only at the beginning of the project. As the work commences, you can use the tools of project design to communicate to management the effect and viability of changes. Appendix A discusses project tracking and managing changes.

除了向开发商和管理人员传达设计外，该方法还允许建筑师准确、轻松地向其他建筑师传达设计。通过这种方式从审查和批评中获得的见解非常宝贵。

Besides communicating the design to developers and managers, The Method allows the architect to accurately and easily communicate the design to other architects. The insights you gain from review and criticism in this manner are invaluable.

功能分解的问题

Problems with Functional Decomposition

功能分解的问题很多而且很严重。至少，功能分解将服务与需求耦合在一起，因为服务是需求的反映。所需功能的任何变化都会对功能服务产生影响。随着时间的推移，这种变化是不可避免的，并且会要求事后进行新的分解以反映新的需求，从而对系统造成痛苦的未来变化。除了对系统进行昂贵的更改之外，功能分解还会妨碍重用并导致系统和客户端过于复杂。

The problems with functional decomposition are many and acute. At the very least, functional decomposition couples services to the requirements because the services are a reflection of the requirements. Any change in the required functionality imposes a change on the functional services. Such changes are inevitable over time and impose a painful future change to your system by requiring a new decomposition after the fact to reflect the new requirements. In addition to costly changes to the system, functional decomposition precludes reuse and leads to overly complex systems and clients.

客户端膨胀和耦合

功能分解通常会导致系统层次结构扁平化。由于每个服务或构建块都专用于特定功能，因此必须有人将这些离散的功能组合成所需的行为。这个人通常是客户。当客户是编排服务的人时，系统将变成一个扁平的两层系统：客户端和服务，任何额外分层的概念都消失了。假设您的系统需要按顺序执行三个操作（或功能）：和A。如图 2-1所示，客户端必须将服务拼接在一起。BC

Functional decomposition often leads to flattening of the system hierarchy. Since each service or building block is devoted to a specific functionality, someone must combine these discrete functionalities into a required behavior. That someone is often the client. When the client is the one orchestrating the services, the system becomes a flat two-tier system: clients and services, and any notion of additional layering is gone. Suppose your system needs to perform three operations (or functionalities): A, B and C, in that order. As illustrated in Figure 2-1, the client must stitch the services together.

通过在客户端中添加编排逻辑，您会用系统的业务逻辑污染客户端代码。客户端不再只是调用系统上的操作或向用户呈现信息。客户端现在非常了解所有内部服务，如何调用它们，如何处理它们的错误，如何B在 成功之后补偿 的失败，A等等。调用服务几乎总是同步的，因为客户端按照预期的顺序进行，A然后，否则很难在保持对外界响应的同时确保调用的顺序。此外，客户端现在与所需的功能耦合在一起。操作中的任何更改（例如调用' 而不是）都会迫使客户端反映该更改。糟糕设计的标志是系统的任何更改都会影响客户端。理想情况下，客户端和服务应该能够独立发展。几十年前，软件工程师发现将业务逻辑包含在客户端中是个坏主意。然而，当按照图 2-1所示进行设计时，您不得不用排序、排序、错误补偿和调用持续时间的业务逻辑来污染客户端。最终，客户端不再是客户端 - 它已经成为系统。BCBB

By bloating the client with the orchestration logic, you pollute the client code with the business logic of the system. The client is no longer just about invoking operations on the system or presenting information to users. The client is now intimately aware of all internal services, how to call them, how to handle their errors, how to compensate for the failure of B after the success of A, and so on. Calling the services is almost always synchronous because the client proceeds along the expected sequence of A then B then C, and it is difficult otherwise to ensure the order of the calls while remaining responsive to the outside world. Furthermore, the client is now coupled to the required functionality. Any change in the operations, such as calling B' instead of B, forces the client to reflect that change. The hallmark of a bad design is when any change to the system affects the client. Ideally, the client and services should be able to evolve independently. Decades ago, software engineers discovered that it was a bad idea to include business logic with the client. Yet, when designed as in Figure 2-1, you are forced to pollute the client with the business logic of sequencing, ordering, error compensation, and duration of the calls. Ultimately, the client is no longer the client—it has become the system.

如果有多个客户端（例如，富客户端、网页、移动设备），每个客户端都试图调用相同的功能服务序列，该怎么办？您注定要在客户端之间复制该逻辑，这使得维护所有这些客户端既浪费又昂贵。随着功能的变化，您现在被迫在多个客户端上跟上这种变化，因为所有客户端都会受到影响。通常，一旦出现这种情况，开发人员就会试图避免对服务的功能进行任何更改，因为这会对客户端产生连锁反应。由于客户端众多，每个客户端都有自己定制的排序版本，因此更改或交换服务变得更加困难，从而阻止在客户端之间重用相同的行为。实际上，您最终需要维护多个复杂的系统，试图使它们保持同步。最终，当更改在开发和生产过程中被迫进行时，这既会扼杀创新，又会延长上市时间。

What if there are multiple clients (e.g., rich clients, web pages, mobile devices), each trying to invoke the same sequence of functional services? You are destined to duplicate that logic across the clients, making maintenance of all those clients wasteful and expensive. As the functionality changes, you now are forced to keep up with that change across multiple clients, since all of them will be affected. Often, once that is the case, developers try to avoid any changes to the functionality of the services because of the cascading effect it will have on the clients. With the multiplicity of clients, each with its own version of the sequencing tailored to its needs, it becomes even more challenging to change or interchange services, thus precluding reuse of the same behavior across the clients. Effectively, you end up maintaining multiple complex systems, trying to keep them all in sync. Ultimately, this leads to both stifling of innovation and increased time to market when the changes are forced through development and production.

作为迄今为止讨论的功能分解问题的一个例子，请考虑图 2-2。这是我审查的一个系统的圈复杂度分析的可视化。使用的设计方法是功能分解。

As an example of the problems with functional decomposition discussed thus far, consider Figure 2-2. It is the visualization of cyclomatic complexity analysis of a system I reviewed. The design methodology used was functional decomposition.

圈复杂度度量的是类或服务代码中独立路径的数量。内部越复杂和耦合，圈复杂度得分就越高。用于生成图 2-2的工具对系统中的各个类进行了测量和评级。在可视化中，类越复杂，其大小和颜色就越深。乍一看，你会看到三个非常大且非常复杂的类。维护 有多容易？这仅仅是一个表单、一个 UI 元素、一个从用户到系统的干净管道，还是它就是系统？观察 的大小和阴影中MainForm设置 所需的复杂性。不甘示弱，非常复杂，因为更改 中使用的资源非常复杂。MainFormFormSetupResourcesMainForm理想情况下，Resources应该是微不足道的，由简单的图像和字符串列表组成。系统的其余部分由数十个小的、简单的类组成，每个类都专用于特定的功能。较小的类实际上处于三个大类的阴影之下。然而，虽然每个小类可能都很微不足道，但小类的数量本身就是一个复杂性问题，涉及这么多类之间的复杂集成。结果是组件太多，组件太大，客户端臃肿。

Cyclomatic complexity measures the number of independent paths through the code of a class or service. The more the internals are convoluted and coupled, the higher the cyclomatic complexity score. The tool used to generate Figure 2-2 measured and rated the various classes in the system. In the visualization, the more complex the class is, the larger and darker it is in color. At first glance, you see three very large and very complex classes. How easy would it be to maintain MainForm? Is this just a form, a UI element, a clean conduit from the user to the system, or is it the system? Observe the complexity required to set up MainForm in the size and shade of FormSetup. Not to be outdone, Resources is very complex, since it is very complex to change the resources used in MainForm. Ideally, Resources should have been trivial, comprising simple lists of images and strings. The rest of the system is made up of dozens of small, simple classes, each devoted to a particular functionality. The smaller classes are literally in the shadow of the three massive ones. However, while each of the small classes may be trivial, the sheer number of the smaller classes is a complexity issue all on its own, involving intricate integration across that many classes. The result is both too many components and too big components as well as a bloated client.

服务膨胀和耦合

作为图 2-1中对功能服务进行排序的替代方法，您可以选择让功能服务相互调用，从表面上看，这种方法似乎两害相权取其轻，如图 2-3所示。

As an alternative to sequencing the functional services as in Figure 2-1, you can opt for what, on the face of it, appears as a lesser evil by having the functional services call each other, as shown in Figure 2-3.

这样做的好处是可以让客户端保持简单，甚至是异步的：客户端向A服务发出调用。A然后服务调用B，并B调用C。

The advantage of doing so is that you get to keep the clients simple and even asynchronous: the clients issue the call to the A service. The A service then calls B, and B calls C.

现在的问题是功能服务彼此耦合，并且与功能调用顺序耦合。例如，您Billing只能在服务之后Invoicing但在服务之前调用服务。在图 2-3Shipping的情况下，服务内置了需要调用 B 服务的知识。只能在服务之后但在服务之前调用服务。调用所需顺序的变化可能会影响链上上下下的所有服务，因为它们的实现必须更改以反映新的所需顺序。ABAC

The problem now is that the functional services are coupled to each other and to the order of the functional calls. For example, you can call the Billing service only after the Invoicing service but before the Shipping service. In the case of Figure 2-3, built into the A service is the knowledge that it needs to call the B service. The B service can be called only after the A service and before the C service. A change in the required ordering of the calls is likely to affect all services up and down the chain because their implementation will have to change to reflect the new required order.

但是图 2-3并未展示全貌。图 2-3B中的服务与图 2-1中的服务截然不同。原始服务仅执行功能。图 2-3中的服务必须了解服务，并且契约必须包含服务执行其功能所需的参数。这些细节是图 2-1中的客户端的责任。问题因服务而变得更加复杂，服务现在必须在其服务契约中容纳调用和服务所需的参数，以使它们执行各自的业务功能。对和功能的任何更改都会反映在服务实现的更改中，而服务实现现在与它们耦合。图 2-4描述了这种膨胀和耦合。BBBCBCABCBCA

But Figure 2-3 does not reveal the full picture. The B service of Figure 2-3 is drastically different from that of Figure 2-1. The original B service performed only the B functionality. The B service in Figure 2-3 must be aware of the C service, and the B contract must contain the parameters that will be required by the C service to perform its functionality. These details were the responsibility of the client in Figure 2-1. The problem is compounded by the A service, which must now accommodate in its service contract the parameters required for calling the B and the C services for them to perform their respective business functionality. Any change to the B and C functionality is reflected in a change to the implementation of the A service, which is now coupled to them. This kind of bloating and coupling is depicted in Figure 2-4.

遗憾的是，即使图 2-4也没有说明全部事实。假设A服务成功执行了A功能，然后继续调用B服务来执行该B功能。B但是，服务遇到了错误，无法正确执行。如果同步A调用B，则A必须密切了解的内部逻辑和状态B才能恢复其错误。这意味着B功能也必须驻留在A服务中。如果异步A调用B，那么B服务现在必须以某种方式返回到A服务并撤消A功能或在其自身内包含回滚A。换句话说，A功能也驻留在服务中。这会导致服务与服务B之间紧密耦合，并导致服务膨胀，需要补偿服务的成功。这种情况如图 2-5所示。BABA

Sadly, even Figure 2-4 does not tell the whole truth. Suppose the A service performed the A functionality successfully and then proceeded to calling the B service to perform the B functionality. The B service, however, encountered an error and failed to execute properly. If A called B synchronously, then A must be intimately aware of the internal logic and state of B in order to recover its error. This means the B functionality must also reside in the A service. If A called B asynchronously, then the B service must now somehow reach back to the A service and undo the A functionality or contain the rollback of A within itself. In other words, the A functionality also resides in the B service. This creates tight coupling between the B service and the A service and bloats the B service with the need to compensate for the success of the A service. This situation is shown in Figure 2-5.

问题在C服务中变得更加复杂。如果A和B功能都成功完成，但C服务未能执行其业务功能，会怎么样？C服务必须返回到B和A服务来撤消它们的操作。这会导致服务更加臃肿，并将其与和服务C耦合在一起。考虑到图 2-5中的耦合和臃肿，如何才能将该服务替换为功能不同于功能的'服务？这会对和服务产生什么不利影响？同样，当在其他上下文中需要服务中的功能时（例如在服务之后和服务之前调用服务），图 2-5中的重用程度如何？、和是三个不同的服务还是一个混乱的混合体？ABBBBACBDEABC

The issue is compounded in the C service. What if both the A and B functionalities succeeded and completed, but the C service failed to perform its business function? The C service must reach back to both the B and the A services to undo their operations. This creates far more bloating in the C service and couples it to the A and B services. Given the coupling and bloating in Figure 2-5, what will it take to replace the B service with a B' service that performs the functionality differently than B? What will be the adverse effects on the A and C services? Again, what degree of reuse exists in Figure 2-5 when the functionality in the services is asked for in other contexts, such as calling the B service after the D service and before the E service? Are A, B, and C three distinct services or just one fused mess?

反思功能分解

Reflecting on Functional Decomposition

功能分解具有几乎不可抗拒的吸引力。它看起来是一种简单明了的系统设计方法，只需要你简单地列出所需的功能，然后在架构中为每个功能创建一个组件。功能分解（及其同类，稍后讨论的域分解）是大多数系统的设计方式。大多数人自然而然地选择功能分解，这很可能是你的计算机科学教授在学校向你展示的。功能分解在设计不良的系统中盛行，这几乎完美地表明了应该避免的事情。无论如何，你必须抵制功能分解的诱惑。

Functional decomposition holds an almost irresistible allure. It looks like a simple and clear way of designing the system, requiring you to simply list the required functionalities and then create a component in your architecture for each. Functional decomposition (and its kin, the domain decomposition discussed later) is how most systems are designed. Most people choose functional decomposition naturally, and it is likely what your computer science professor showed you in school. The prevalence of functional decomposition in poorly designed systems makes a near-perfect indicator of something to avoid. At all costs, you must resist the temptations of functional decomposition.

例如：功能性住宅

事实上，永远不要使用功能分解进行设计，这是一个普遍的看法，与软件系统无关。考虑从功能上建造一栋房子，就好像它是一个软件系统。首先列出房子所需的所有功能，例如烹饪、玩耍、休息、睡觉等。然后，在架构中为每个功能创建一个实际组件，如图2-6所示。

The fact you should never design using functional decomposition is a universal observation that has nothing to do with software systems. Consider building a house functionally, as if it were a software system. You start by listing all the required functionalities of the house, such as cooking, playing, resting, sleeping, and so on. You then create an actual component in the architecture for each functionality, as shown in Figure 2-6.

虽然图 2-6已经很荒谬了，但真正的疯狂只有在建造这栋房子的时候才会显现出来。你从一块干净的土地开始，建造厨房。只是做饭。你从盒子里拿出微波炉放在一边。倒上一个小混凝土垫，在垫子上建一个木框架，盖上台面，把微波炉放在上面。为微波炉建一个小食品储藏室，在上面用锤子敲一个小屋顶，只把微波炉连接到电网上。“我们做饭了！”你向老板和顾客宣布。

While Figure 2-6 is already preposterous, the true insanity becomes evident only when it is time to build this house. You start with a clean plot of land and build cooking. Just cooking. You take a microwave oven out of its box and put it aside. Pour a small concrete pad, build a wood frame on the pad, cover it with countertop, and place the microwave on it. Build a small pantry for the microwave and hammer a tiny roof over it, connect just the microwave to the power grid. “We have cooking!” you announce to the boss and customers.

但烹饪真的完成了吗？烹饪能以这种方式完成吗？你在哪里上菜、储存剩菜或处理垃圾？在煤气炉上做饭怎么样？如何才能复制这种烹饪方式？炉子？在两种不同的烹饪功能表达方式之间，你能实现多大程度的重用？你可以轻松地扩展其中任何一种吗？在其他地方用微波炉做饭怎么样？重新安置微波炉需要做些什么？所有这些乱象甚至还不是开始，因为这完全取决于你进行的烹饪类型。如果烹饪涉及多种器具且因情况而异，你可能需要构建单独的烹饪功能 — — 例如，如果你要煮早餐、午餐、晚餐、甜点或小吃。你最终要么得到大量微小烹饪服务，每种服务都专用于必须提前知道的特定场景，要么得到拥有一切的大规模烹饪服务。你会建这样的房子吗？如果没有，为什么要以这种方式设计和构建软件系统？

But is cooking really done? Can cooking ever be done this way? Where are you serving the meal, storing the leftovers, or disposing of trash? What about cooking over the gas stove? What will it take to duplicate this feat for cooking over the stove? What degree of reuse can you have between the two separate ways of expressing the functionality of cooking? Can you extend any one of them easily? What about cooking with a microwave somewhere else? What does it take to relocate the microwave? All of this mess is not even the beginning because it all depends on the type of cooking you perform. You need to build separate cooking functionality, perhaps, if cooking involves multiple appliances and differs by context—for example, if you are cooking breakfast, lunch, dinner, dessert, or snacks. You end up with either explosion of minute cooking services, each dedicated to a specific scenario that must be known in advance, or you end up with massive cooking service that has it all. Will you ever build a house like that? If not, why design and build a software system that way?

何时使用功能分解

When To Use Functional Decomposition

这些页面中的嘲笑并不意味着功能分解是个坏主意。功能分解有其用处——它是一种不错的需求发现技术。它可以帮助架构师（或产品经理）发现隐藏或隐含的功能区域。从顶部开始，即使功能需求很模糊，您也可以将功能分解到非常精细的水平，揭示需求及其关系，以树状方式排列需求，并识别冗余或互斥的功能。然而，将功能分解扩展到设计中是致命的。需求和设计之间永远不应该有直接的映射。

The derision in these pages does not mean functional decomposition is a bad idea. Functional decomposition has a place—it is a decent requirements discovery technique. It helps architects (or product managers) discover hidden or implied areas of functionality. Starting at the top, even with vague functional requirements, you can drive functional decomposition to a very fine level, uncovering requirements and their relationship, arranging the requirements in a tree-like manner, and identifying redundancies or mutually exclusive functionalities. Extending functional decomposition into a design, however, is deadly. There should never be direct mapping between the requirements and the design.

避免域分解

Avoid Domain Decomposition

图 2-6中的房屋设计显然是荒谬的。在你的房子里，你很可能在厨房做饭，所以图 2-7显示了房屋的另一种分解方式。这种分解形式称为域分解：根据业务领域（如销售、工程、会计和运输）将系统分解为构建块。遗憾的是，图 2-7所示的域分解甚至比图 2-6的功能分解还要糟糕。域分解不起作用的原因是它仍然是伪装的功能分解：Kitchen是你做饭的地方，Bedroom是你睡觉的地方，Garage是你停车的地方，等等。

The house design in Figure 2-6 is obviously absurd. In your house, you likely do the cooking in the kitchen, so an alternative decomposition of the house is shown in Figure 2-7. This form of decomposition is called domain decomposition: decomposing a system into building blocks based on the business domains, such as sales, engineering, accounting, and shipping. Sadly, domain decomposition such as Figure 2-7 shows is even worse than the functional decomposition of Figure 2-6. The reason domain decomposition does not work is that it is still functional decomposition in disguise: Kitchen is where you do the cooking, Bedroom is where you do the sleeping, Garage is where you do the parking, and so on.

事实上，图 2-6中的每个功能区域都可以映射到图 2-7中的域，这会带来严重的问题。虽然每个卧室可能都是独一无二的，但你必须在所有卧室中复制睡眠功能。当在客厅的电视机前睡觉或在厨房招待客人时（因为几乎所有的家庭聚会都在厨房举行），就会发生进一步的重复。每个域通常都会演变成丑陋的功能大杂烩，从而增加了域的内部复杂性。增加的内部复杂性使您避免了跨域连接的痛苦，跨域通信通常简化为简单的状态更改（类似 CRUD），而不是触发涉及所有域的必需行为执行的操作。跨域组合更复杂的行为非常困难。在这样的域分解中，某些功能根本无法实现。例如，在图 2-7中的房子里，您会在哪里进行无法在厨房进行的烹饪（例如，烧烤）？

In fact, every one of the functional areas of Figure 2-6 can be mapped to domains in Figure 2-7, which presents severe problems. While each bedroom may be unique, you must duplicate the functionality of sleeping in all of them. Further duplication occurs when sleeping in front of the TV in the living room or when entertaining guests in the kitchen (as almost all house parties end up in the kitchen). Each domain often devolves into an ugly grab bag of functionality, increasing the internal complexity of the domain. The increased inner complexity causes you to avoid the pain of cross-domain connectivity, and communication across domains is typically reduced to simple state changes (CRUD-like) rather than actions triggering required behavior execution involving all domains. Composing more complex behaviors across domains is very difficult. Some functionalities are simply impossible in such domain decompositions. For example, in the house in Figure 2-7, where would you perform cooking that cannot take place in the kitchen (e.g., a barbecue)?

错误的动机

Faulty Motivation

功能或领域分解的动机是业务或客户希望尽快实现其功能。问题是您永远无法孤立地部署单个功能。Billing独立于Invoicing和没有任何商业价值Shipping。

The motivation for functional or domain decomposition is that the business or the customer wants its feature as soon as possible. The problem is that you can never deploy a single feature in isolation. There is no business value in Billing independent from Invoicing and Shipping.

如果涉及遗留系统，情况就更糟了。开发人员很少有机会开发全新的绿地系统。最有可能的是，现有系统功能设计得很糟糕，但其灵活性和维护成本却足以证明开发新系统是合理的。

The situation is even worse when legacy systems are involved. Rarely do developers get the privilege of a completely new, green-field system. Most likely there is an existing, decaying system that was designed functionally whose inflexibility and maintenance costs justify the new system.

假设您的企业在遗留系统中运行三个功能A、B和C。在构建新系统替换旧系统时，您决定先构建并（更重要的是）部署该功能，以满足希望尽早并经常看到价值的客户和经理。问题在于，企业本身A没有必要使用仅仅。企业还需要和。在新系统和旧系统中执行和将行不通，因为旧系统不了解新系统，无法仅仅执行和。同时在旧系统和新系统中执行不会增加任何价值，甚至由于重复工作而产生负价值，因此用户可能会反抗。唯一的解决方案是以某种方式协调新旧系统。协调的复杂性通常远远超过原始底层业务问题的挑战，因此开发人员最终要解决的是一个更为复杂的问题。再次使用房屋类比，如果住在狭窄的老房子里，而又按照图 2-6或图 2-7在城镇的另一边建造新房子，那会是什么感觉？假设你只在新房子里建造厨房或烹饪区，而你继续住在老房子里。每次你饿了，你都必须开车去新房子再回来。你不会接受你的房子，所以你不应该对你的顾客施加这种虐待。ABCABCBCA

Suppose your business has three functionalities A, B, and C, running in a legacy system. When building a new system to replace the old, you decide to build and, more important, deploy the A functionality first to satisfy the customers and managers who wish to see value early and often. The problem is that the business has no use for just A on its own. The business needs B and C as well. Performing A in the new system and B and C in the old system will not work, because the old system does not know about the new system and cannot execute just B and C. Doing A in both the old system and the new system adds no value and even has negative value due to the repeated work, so users are likely to revolt. The only solution is to somehow reconcile the old and the new systems. The reconciliation typically far eclipses in complexity the challenge of the original underlying business problem, so developers end up solving a far more complex problem. To use the house analogy again, what would it be like to live in a cramped old house while building a new house on the other side of town according to Figure 2-6 or Figure 2-7? Suppose you are building just cooking or the kitchen in the new house while continuing to live in the old house. Every time you are hungry, you have to drive to the new house and come back. You would not accept it with your house, so you should not inflict this kind of abuse on your customers.

可测试性和设计

Testability and Design

功能分解和领域分解的一个关键缺陷与测试有关。在这种设计中，耦合度和复杂度非常高，开发人员唯一能做的测试就是单元测试。然而，这并不意味着单元测试很重要，它只是路灯效应¹的另一个例子（即在最容易看到的地方寻找东西）。

A crucial flaw of both functional and domain decomposition has to do with testing. With such designs, the level of coupling and complexity is so high that the only kind of testing developers can do is unit testing. However, that does not make unit testing important, and it is merely another example of the streetlight effect¹ (i.e., searching for something where it is easiest to look).

1. https://en.wikipedia.org/wiki/Streetlight_effect

1. https://en.wikipedia.org/wiki/Streetlight_effect

可悲的现实是，单元测试几乎毫无用处。虽然单元测试是测试的重要组成部分，但它无法真正测试系统。考​​虑一架拥有众多内部组件（泵、执行器、伺服器、齿轮、涡轮机等）的大型喷气式飞机。现在假设所有组件都已独立完美地通过了单元测试，但这是组件组装成飞机之前进行的唯一测试。你敢登上那架飞机吗？单元测试如此边缘化的原因是，在任何复杂系统中，缺陷不会出现在任何单元中，而是单元之间相互作用的结果。这就是为什么你本能地知道，虽然大型喷气式飞机示例中的每个组件都可以工作，但总体可能会出现严重错误。更糟糕的是，即使复杂系统处于无可挑剔的质量完美状态，更改单个经过单元测试的组件也可能会破坏依赖旧行为的其他单元。你必须更改单个单元时，重复测试所有单元。即使这样，这也毫无意义，因为对其中一个组件的更改可能会影响其他组件或子系统之间的某些交互，而单元测试无法发现这一点。验证更改的唯一方法是对系统、其子系统、其组件和交互以及最终的单元进行完整的回归测试。如果由于您的更改，其他单元需要更改，则对回归测试的影响是非线性的。单元测试的无效性并不是一个新发现，并且已在数千个经过良好测量的系统中得到证实。

The sad reality is that unit testing is borderline useless. While unit testing is an essential part of testing, it cannot really test a system. Consider a jumbo jet that has numerous internal components (pumps, actuators, servos, gears, turbines, etc.). Now suppose all components have independently passed unit testing perfectly, but that is the only testing that took place before the components were assembled into an aircraft. Would you dare board that airplane? The reason unit testing is so marginal is that in any complex system, the defects are not going to be in any of the units but rather are the result of the interactions between the units. This is why you instinctively know that, while each component in the jumbo jet example works, the aggregate could be horribly wrong. Worse, even if the complex system is at a perfect state of impeccable quality, changing a single, unit-tested component could break some other unit(s) relying on an old behavior. You must repeat testing of all units when changing a single unit. Even then it would be meaningless because the change to one of the components could affect some interaction between other components or a subsystem, which no unit testing could discover. The only way to verify change is full regression testing of the system, its subsystems, its components and interactions, and finally its units. If, as a result of your change, other units need to change, the effect on regression testing is nonlinear. The inefficacy of unit testing is not a new observation and has been demonstrated across thousands of well-measured systems.

理论上，您甚至可以在功能分解的系统上执行回归测试。实际上，这项任务的复杂性将标准定得非常高。功能组件的数量之多使得测试所有交互变得不切实际。非常大的服务内部非常复杂，以至于没有人能够有效地设计出一种全面的策略来测试通过此类服务的所有代码路径。使用功能分解，大多数开发人员都会放弃并只执行简单的单元测试。因此，通过排除回归测试，功能分解使整个系统无法测试，而无法测试的系统总是充满缺陷。

In theory, you could perform regression testing even on a functionally decomposed system. In practice, the complexity of that task would set the bar very high. The sheer number of the functional components would make testing all the interactions impractical. The very large services would be internally so complex that no one could effectively devise a comprehensive strategy that tests all code paths through such services. With functional decomposition, most developers give up and perform just simple unit testing. Therefore, by precluding regression testing, functional decomposition makes the entire system untestable, and untestable systems are always rife with defects.

示例：功能交易系统

Example: Functional Trading System

不同于房屋，我们来考虑一下金融公司对股票交易系统的以下简化要求：

Instead of a house, consider the following simplified requirements for a stock trading system for a financial company:

• 该系统应允许内部交易员：

  – 买卖股票

  – 安排交易

  – 发布报告

  – 分析交易

• The system should enable in-house traders to:

  –  Buy and sell stocks

  –  Schedule trades

  –  Issue reports

  –  Analyze the trades

• 系统用户利用浏览器连接到系统并管理连接的会话、填写表格并提交请求。

• The users of the system utilize a browser to connect to the system and manage connected sessions, completing a form and submitting the request.

• 交易、报告或分析请求后，系统会向用户发送一封电子邮件，确认他们的请求或包含结果。

• After a trade, report, or analysis request, the system sends an email to the users confirming their request or containing the results.

• 数据应存储在本地数据库中。

• The data should be stored in a local database.

直接的功能分解将产生图 2-8的设计。

A straightforward functional decomposition would yield the design of Figure 2-8.

每个功能需求都体现在架构的相应组件中。图 2-8表示许多新手软件开发人员会毫不犹豫地采用的常见设计。

Each of the functional requirements is expressed in a respective component of the architecture. Figure 2-8 represents a common design to which many novice software developers would gravitate without hesitation.

分解、维护和开发

Decomposition, Maintenance, and Development

如前所述，功能分解大大增加了系统的复杂性。功能分解也使维护成为一场噩梦。此类系统中的代码不仅复杂，而且更改会分散在多个服务中。这使得维护代码需要大量劳动力、容易出错且非常耗时。通常，代码越复杂，其质量就越低，而低质量会使维护更具挑战性。您必须应对高复杂性，避免在解决旧缺陷的同时引入新缺陷。在功能分解的系统中，由于低质量和复杂性的结合，新更改导致新缺陷的情况很常见。扩展功能系统通常需要付出的努力与客户的利益不成比例。

As explained previously, functional decomposition drastically increases the system’s complexity. Functional decomposition also makes maintenance a nightmare. Not only is the code in such systems complex, changes are spread across multiple services. This makes maintaining the code labor intensive, error prone, and very time-consuming. Generally, the more complex the code, the lower its quality, and low quality makes maintenance even more challenging. You must contend with high complexity and avoid introducing new defects while resolving old ones. In a functionally decomposed system, it is common for new changes to result in new defects due to the confluence of low quality and complexity. Extending the functional system often requires effort disproportionally expensive with respect to the benefit to the customer.

甚至在维护开始之前，当系统处于开发阶段时，功能分解就存在危险。需求会在整个开发过程中发生变化（这是不可避免的），每次变化的成本都很大，影响多个领域，迫使大量返工，最终危及最后期限。

Even before maintenance ever starts, when the system is under development, functional decomposition harbors danger. Requirements will change throughout development (as they invariably do), and the cost of each change is huge, affecting multiple areas, forcing considerable rework, and ultimately endangering the deadline.

采用基于波动性的分解设计的系统在响应变化的能力方面呈现出鲜明的对比。由于每个模块都包含变化，因此至少有希望实现易于维护且不会对模块边界外产生副作用。复杂性降低且维护更简单，质量大大提高。如果某些东西以相同的方式封装在另一个系统中，您就有机会重用。您可以通过添加更多封装波动性区域来扩展系统，或者以不同的方式集成现有的波动性区域。封装波动性意味着在开发过程中对功能蔓延的弹性要好得多，并且有机会满足进度，因为变化将得到控制。

Systems designed with volatility-based decomposition present a stark contrast in their ability to respond to change. Since changes are contained in each module, there is at least a hope for easy maintenance with no side effects outside the module boundary. With lower complexity and easier maintenance, quality is much improved. You have a chance at reuse if something is encapsulated the same way in another system. You can extend the system by adding more areas of encapsulated volatility or integrate existing areas of volatility in a different way. Encapsulating volatility means far better resiliency to feature creep during development and a chance of meeting the schedule, since changes will be contained.

普遍原则

Universal Principle

基于波动性的分解的优点并不局限于软件系统。它们是良好设计的通用原则，从商业到业务交互，从生物学到物理系统和优秀软件。通用原则本质上也适用于软件（否则它们就不是通用的）。例如，考虑一下你自己的身体。你自己身体的功能分解将包含你需要完成的每一项任务的组件，从驾驶到编程再到演示，但你的身体没有任何这样的组件。你通过整合波动性领域来完成编程等任务。例如，你的心脏为你的系统提供一项重要服务：泵血。泵血具有巨大的波动性：高血压和低压、盐度、粘度、脉搏率、活动水平（坐着或跑步）、有无肾上腺素、不同的血型、健康和生病等等。然而，所有这些波动性都封装在称为心脏的服务背后。如果你必须关心泵血所涉及的波动性，你还能编程吗？

The merits of volatility-based decomposition are not specific to software systems. They are universal principles of good design, from commerce to business interactions to biology to physical systems and great software. Universal principles, by their very nature, apply to software too (else they would not be universal). For example, consider your own body. A functional decomposition of your own body would have components for every task you are required to do, from driving to programming to presenting, yet your body does not have any such components. You accomplish a task such as programming by integrating areas of volatility. For example, your heart provides an important service for your system: pumping blood. Pumping blood has enormous volatility to it: high blood pressure and low pressure, salinity, viscosity, pulse rate, activity level (sitting or running), with and without adrenaline, different blood types, healthy and sick, and so on. Yet all that volatility is encapsulated behind the service called the heart. Would you be able to program if you had to care about the volatility involved in pumping blood?

您还可以将封装的波动性外部区域集成到您的实现中。考虑一下您的计算机，它与世界上任何其他计算机都不同，但所有波动性都被封装了。只要计算机可以向屏幕发送信号，您就不必关心图形端口后面发生了什么。您可以通过集成封装的波动性区域（一些内部区域，一些外部区域）来执行编程任务。您可以在执行其他功能（例如驾驶汽车或向客户展示您的工作）时重用相同的波动性区域（例如心脏）。根本没有其他方法来设计和构建可行的系统。

You can also integrate into your implementation external areas of encapsulated volatility. Consider your computer, which is different from literally any other computer in the world, yet all that volatility is encapsulated. As long as the computer can send a signal to the screen, you do not care what happens behind the graphic port. You perform the task of programming by integrating encapsulated areas of volatility, some internal, some external. You can reuse the same areas of volatility (such as the heart) while performing other functionalities such as driving a car or presenting your work to customers. There is simply no other way of designing and building a viable system.

根据波动性进行分解是系统设计的精髓。所有设计良好的系统，无论是软件系统还是物理系统，都将其波动性封装在系统的构建块中。

Decomposing based on volatility is the essence of system design. All well-designed systems, software and physical systems alike, encapsulate their volatility inside the system’s building blocks.

基于波动性的分解和测试

Volatility-Based Decomposition and Testing

基于波动性的分解非常适合回归测试。组件数量的减少、组件大小的减小以及组件之间交互的简化都大大降低了系统的复杂性。这使得编写回归测试成为可能，该测试可以端到端地测试系统、单独测试每个子系统并最终测试独立的组件。由于基于波动性的分解包含系统构建块内部的变化，因此一旦不可避免的变化发生，它们不会破坏现有的回归测试。您可以独立于系统的其余部分测试组件更改的影响，而不会干扰组件间和子系统间的测试。

Volatility-based decomposition lends well to regression testing. The reduction in the number of components, the reduction in the size of components, and the simplification of the interactions between components all drastically reduce the complexity of the system. This makes it feasible to write regression testing that tests the system end to end, tests each subsystem individually, and eventually tests independent components. Since volatility-based decomposition contains the changes inside the building blocks of the system, once the inevitable changes do happen, they do not disrupt the regression testing in place. You can test the effect of a change in a component in isolation from the rest of the system without interfering with the inter-components and inter-subsystems testing.

波动性的挑战

The Volatility Challenge

基于波动性的分解背后的想法和动机简单、实用，并且符合现实和常识。执行基于波动性的分解的主要挑战与时间、沟通和感知有关。您会发现波动性通常不是不言而喻的。在项目开始时，没有哪个客户或产品经理会以以下方式向您展示系统需求：“这可能会改变，我们稍后会改变那个，我们永远不会改变那些。” 外界（无论是客户、管理层还是营销部门）总是向您展示功能方面的要求：“系统应该做这个和那个。” 即使是您，在阅读这些页面时，也可能在您尝试识别当前系统中的波动区域时，很难理解这个概念。因此，与功能分解相比，基于波动的分解需要更长的时间。

The ideas and motivations behind volatility-based decomposition are simple, practical, and consistent with reality and common sense. The main challenges in performing a volatility-based decomposition have to do with time, communication, and perception. You will find that volatility is often not self-evident. No customer or product manager at the onset of a project will ever present you the requirements for the system the following way: “This could change, we will change that one later, and we will never change those.” The outside world (be it customers, management, or marketing) always presents you with requirements in terms of functionality: “The system should do this and that.” Even you, reading these pages, are likely struggling to wrap your head around this concept as you to try to identify the areas of volatility in your current system. Consequently, volatility-based decomposition takes longer compared with functional decomposition.

请注意，基于波动性的分解并不意味着您应该忽略需求。您必须分析需求以识别波动性区域。可以说，需求分析的整个目的就是识别波动性区域，而这种分析需要付出努力和汗水。这实际上是个好消息，因为现在您有机会遵守热力学第一定律。遗憾的是，仅仅为问题付出努力并不意味着什么。热力学第一定律并没有说如果你为某事付出努力，你就会创造价值。创造价值要困难得多。本书为您提供了设计和分析的强大思维工具，包括结构、指南和合理的工程方法。这些工具让您在追求创造价值的过程中有机会一搏。您仍然必须练习和奋斗。

Note that volatility-based decomposition does not mean you should ignore the requirements. You must analyze the requirements to recognize the areas of volatility. Arguably, the whole purpose of requirements analysis is to identify the areas of volatility, and this analysis requires effort and sweat. This is actually great news because now you are given a chance to comply with the first law of thermodynamics. Sadly, merely sweating on the problem does not mean a thing. The first law of thermodynamics does not state that if you sweat on something, you will add value. Adding value is much more difficult. This book provides you with powerful mental tools for design and analysis, including structure, guidelines, and a sound engineering methodology. These tools give you a fighting chance in your quest to add value. You still must practice and fight.

易变性与可变性

Volatile Versus Variable

许多新手所困惑的一个关键问题是变化的事物和易变的事物之间的区别。并非所有可变的事物都是易变的。只有当易变性是开放式的，并且除非将其封装在架构的组件中，否则包含它的成本将非常高时，您才可以在系统设计级别封装它。另一方面，可变性描述的是那些您可以使用条件逻辑在代码中轻松处理的方面。在寻找易变性时，您应该留意会对整个系统产生连锁反应的那种变化或风险。变化不得使架构失效。

A key question many novices struggle with is the difference between things that change and things that are volatile. Not everything that is variable is also volatile. You resort to encapsulating a volatility at the system design level only when it is open-ended and, unless encapsulated in a component of the architecture, would be very expensive to contain. Variability, on the other hand, describes those aspects that you can easily handle in your code using conditional logic. When searching for volatility, you should be on the lookout for the kind of changes or risks that would have ripple effects across the system. Changes must not invalidate the architecture.

波动轴

Axes Of Volatility

寻找波动领域是一个发现过程，发生在需求分析和与项目利益相关者的访谈过程中。

Finding areas of volatility is a process of discovery that takes place during requirements analysis and interviews with the project stakeholders.

有一种简单的技术，我称之为波动轴。该技术检查客户使用系统的方式。在这种情况下，客户是指系统的消费者，可以是单个用户或整个其他商业实体。

There is a simple technique I call axes of volatility. This technique examines the ways the system is used by customers. Customer in this context refers to a consumer of the system, which could be a single user or a whole other business entity.

在任何业务中，系统面临变化的方式只有两种：第一个轴心是随着时间的推移，同一个客户。即使目前系统完全符合特定客户的需求，但随着时间的推移，该客户的业务环境也会发生变化。甚至客户对系统的使用也常常会改变最初编写系统时所针对的要求。3随着时间的^推移，客户对系统的要求和期望也会发生变化。

In any business, there are only two ways your system could face change: the first axis is at the same customer over time. Even if presently the system is perfectly aligned with a particular customer’s needs, over time, that customer’s business context will change. Even the use of the system by the customer will often change the requirements against which it was written in the first place.³ Over time, the customer’s requirements and expectation of the system will change.

3.解决方案往往会改变其开发要求，这一趋势最早是由 19 世纪英国经济学家威廉·杰文斯 (William Jevons) 在研究煤炭生产时发现的，此后被称为杰文斯悖论。其他表现形式包括随着数字办公的兴起，纸张消耗量增加，以及随着道路容量增加，交通拥堵情况恶化。

3. The tendency of a solution to change the requirements against which it was developed was first observed by the 19th-century English economist William Jevons with regard to coal production, and it is referred to since as the Jevons paradox. Other manifestations are the increase in paper consumption with the digital office and the worsening traffic congestion following an increase in road capacity.

第二种变化是同时发生在客户身上。如果你能暂停时间并检查你的客户群，你现在所有的客户是否都以完全相同的方式使用系统？他们中有些人的做法与其他人有什么不同？你必须适应这些差异吗？所有这些变化定义了波动的第二个轴。

The second way change could come is at the same time across customers. If you could freeze time and examine your customer base, are all your customers now using the system in exactly the same way? What are some of them doing that is different from the others? Do you have to accommodate such differences? All such changes define the second axis of volatility.

在访谈中寻找潜在波动性时，您会发现用波动性轴（同一客户随时间的变化、所有客户在同一时间点的变化）来表述问题非常有帮助。以这种方式提出问题有助于您识别波动性。如果某些东西没有映射到波动性轴，您根本不应该封装它，并且您的系统中不应该有它映射到的构建块。创建这样的块可能表明功能分解。

When searching for potential volatility in interviews, you will find it very helpful to phrase the questions in terms of the axes of volatility (same customer over time, all customers at the same point in time). Framing the questions in this way helps you identify the volatilities. If something does not map to the axes of volatility, you should not encapsulate it at all, and there should be no building block in your system to which it is mapped. Creating such a block would likely indicate functional decomposition.

设计分解

通常，使用波动轴寻找波动区域的行为是一个迭代过程，与设计本身的分解交织在一起。例如，请考虑图 2-10中的设计迭代进展。

Often, the act of looking for areas of volatility using the axes of volatility is an iterative process interleaved with the factoring of the design itself. Consider, for example, the progression of design iterations in Figure 2-10.

您对所提议架构的第一印象可能看起来像图 A — 一个大组件，一个单一组件。问问自己，您能永远对某个特定客户使用相同的组件吗？如果答案是否定的，那么为什么？通常，这是因为您知道客户会随着时间的推移想要改变某个特定的东西。在这种情况下，您必须封装那个东西，产生图 B。现在问自己，您现在可以对所有客户使用图 B 吗？如果答案是否定的，那么找出客户想要做不同的事情，封装它，并生成图 C。您继续以这种方式分解设计，直到将波动轴上的所有可能点都封装起来。

Your first take of the proposed architecture might look like diagram A—one big thing, one single component. Ask yourself, Could you use the same component, as is, with a particular customer, forever? If the answer is no, then why? Often, it is because you know that customer will, over time, want to change a specific thing. In that case, you must encapsulate that thing, yielding diagram B. Ask yourself now, Could you use diagram B across all customers now? If the answer is no, then identify the thing that the customers want to do differently, encapsulate it, and produce diagram C. You keep factoring the design that way until all possible points on the axes of volatility are encapsulated.

示例：基于波动性的房屋分解

您可以使用波动轴来概括房屋的波动性。首先看看您自己的房子，观察它随着时间的推移是如何变化的。例如，考虑家具。随着时间的推移，您可能会重新布置客厅里的家具，偶尔添加新家具或更换旧家具。结论是，房屋中的家具是不稳定的。接下来考虑电器。随着时间的推移，您可能会改用节能电器。您可能已经用平板等离子屏幕替换了旧的 CRT，并用超薄的大型 OLED 电视替换了旧的 CRT。这强烈表明您家中的电器是不稳定的。房子里的居住者怎么样？这方面是静态的吗？您曾经有客人来过吗？房子里可以没有人吗？房子里的居住者是变化无常的。外观怎么样？您是否曾经粉刷过房子、更换过窗帘或美化过环境？房子的外观是不稳定的。房子可能连接到一些公用设施，从互联网到电力和安全。之前，我指出了房屋中的电力波动性，但互联网呢？在过去的几年里，您可能使用拨号上网，然后转向 DSL，然后是电缆，现在是光纤或卫星连接。虽然这些选项截然不同，但您不会想根据连接类型改变发送电子邮件的方式。您应该将所有公用事业的波动性封装起来。图 2-11显示了沿第一个波动轴（同一客户随时间变化）的这种可能分解。

You can use the axes of volatility to encapsulate the volatility of a house. Start by looking at your own house and observe how it changes over time. For example, consider furniture. Over time, you may rearrange the furniture in the living room and occasionally add new pieces or replace old ones. The conclusion is that furniture in a house is volatile. Next consider appliances. Over time, you may switch to energy-efficient appliances. You likely have already replaced the old CRT with flat plasma screen and that with a large, wafer-thin OLED TV. This is a strong indication that at your house, appliances are volatile. How about the occupants of the house? Is that aspect static? Do you ever have guests come over? Can the house be empty of people? The occupants of the house are volatile. What about appearance? Do you ever paint the house, change the draperies or landscaping? The appearance of a house is volatile. The house is likely connected to some utilities, from Internet to power and security. Previously, I pointed out the power volatility in a house, but what about Internet? In years past, you may have used dial-up for Internet, then moved to DSL, then cable, and now fiber optics or a satellite connection. While these options are drastically different, you would not want to change the way you send emails based on the type of connectivity. You should encapsulate the volatilities of all utilities. Figure 2-11 shows this possible decomposition along the first axis of volatility (same customer over time).

现在，即使在同一时间点，你的房子是否与其他所有房子都一样？其他房子的结构不同，因此房子的结构是不稳定的。即使你将你的房子复制粘贴到另一个城市，它还是同一所房子吗？⁴答案显然是否定的。这所房子将有不同的邻居，并受不同城市法规、建筑规范和税收的约束。图 2-12显示了沿第二条波动轴（同一时间点的不同客户）的这种可能分解。

Now, even at the same point in time, is your house the same as every other house? Other houses have a different structure, so the structure of the house is volatile. Even if you were to copy and paste your house to another city, would it be the same house?⁴ The answer is clearly negative. The house will have different neighbors and be subjected to different city regulations, building codes, and taxes. Figure 2-12 shows this possible decomposition along the second axis of volatility (different customers at the same point in time).

4.古希腊人在忒修斯悖论中努力解答了这个问题（https://en.wikipedia.org/wiki/Ship_of_Theseus）。

4. The ancient Greeks grappled with this question in Theseus’s paradox (https://en.wikipedia.org/wiki/Ship_of_Theseus).

请注意轴的独立性。随着时间的推移，您所居住的城市确实会改变其法规，但变化的速度很慢。同样，只要您住在同一所房子里，新邻居出现的可能性就相当低，但如果您在同一时间点将您的房子与另一所房子进行比较，则出现新邻居的可能性是肯定的。因此，将波动性分配给其中一个轴并不是绝对排除，而更像是不成比例的概率。

Note the independence of the axis. The city where you live over time does change its regulations, but the changes come at a slow pace. Similarly, the likelihood of new neighbors is fairly low as long as you live in the same house but is a certainty if you compare your house to another at the same point in time. The assignment of a volatility to one of the axes is therefore not an absolute exclusion but more one of disproportional probability.

还要注意的是，该Neighbors Volatility组件可以处理同一房屋内邻居随时间变化的波动，就像它可以在同一时间点处理不同房屋的波动一样容易。将组件分配给轴有助于首先发现波动性；波动性在同一时间点的不同房屋之间更加明显。

Note also that the Neighbors Volatility component can deal with volatility of neighbors at the same house over time as easily as it can do that across different houses at the same point in time. Assigning the component to an axis helps to discover the volatility in the first place; the volatility is just more apparent across different houses at the same point in time.

最后，与图 2-6和图 2-7的分解形成鲜明对比的是，图 2-11和图 2-12中的分解中没有烹饪或厨房的组件。在基于波动性的分解中，所需的行为是通过各种封装的波动性区域之间的相互作用来实现的。烹饪晚餐可能是居住者、电器、结构和公用设施之间相互作用的产物。由于仍然需要某种东西来管理这种相互作用，因此设计并不完整。波动性轴是一个很好的起点，但它并不是解决问题的唯一工具。

Finally, in sharp contrast to the decompositions of Figure 2-6 and Figure 2-7, in Figure 2-11 and Figure 2-12 there is no component in the decomposition for cooking or kitchen. In a volatility-based decomposition, the required behavior is accomplished by an interaction between the various encapsulated areas of volatility. Cooking dinner may be the product of an interaction between the occupants, the appliances, the structure, and the utilities. Since something still needs to manage that interaction, the design is not complete. The axes of volatility are a great starting point, but it is not the only tool to bring to bear on the problem.

伪装成需求的解决方案

Solutions Masquerading As Requirements

再考虑一下房屋支持烹饪功能的功能需求。此类需求在需求规范中很常见，许多开发人员只需将其映射到Cooking其架构中的组件即可。然而，烹饪并不是一项要求（即使它包含在要求规范中）。烹饪是满足家中人员吃饭需求的一种可能解决方案。您可以通过订购披萨或带家人出去吃饭来满足吃饭需求。

Consider again the functional requirement for the house to support the cooking feature. Such requirements are quite common in requirements specs, and many developers will simply map that to a Cooking component in their architecture. Cooking, however, is not a requirement (even though it was in the requirement spec). Cooking is a possible solution for the requirement of feeding the people in the house. You can satisfy the feeding requirement by ordering pizza or taking the family out for dinner.

客户提供伪装成需求的解决方案的情况极为常见。使用功能分解后，一旦您部署的系统只有Cooking，客户就会要求提供披萨选项，从而导致系统中出现另一个组件或另一个组件膨胀。“外出就餐”的需求很快就会出现，导致功能围绕实际需求不断循环。使用基于波动性的分解，在需求分析期间，您应该确定为乘客提供餐食的波动性并为其提供餐食。餐食的波动性封装在Feeding组件中，并且随着餐食选项的变化，您的设计不会发生变化。

It is exceedingly common for customers to provide solutions masquerading as requirements. With functional decomposition, once you deploy the system with only Cooking, the customer will ask for the pizza option, resulting in either another component in your system or bloating of another component. The “going out to dinner” requirement will soon follow, leading to a never-ending cycle of features going around and around the real requirement. With volatility-based decomposition, during requirements analysis, you should identify the volatility in feeding the occupants and provide for it. The volatility of feeding is encapsulated within the Feeding, component and as the feeding options change, your design does not.

然而，虽然喂食是比烹饪更好的要求，但它仍然是伪装成要求的解决方案。如果为了节食，家里的人今晚应该饿着肚子睡觉怎么办？喂食要求和节食要求可能互相排斥。你可以做其中之一，但不能同时做两者。互相排斥的要求也很常见。

However, while feeding is a better requirement than cooking, it is still a solution masquerading as a requirement. What if in the interest of diet, the people in the house should go to bed hungry tonight? A feeding requirement and diet requirement might be mutually exclusive. You can do either one, but not both. Mutually exclusive requirements are also quite common.

任何房屋的真正要求是照顾居住者的幸福感，而不仅仅是他们的卡路里摄入量。房子不应该太冷或太热，太潮湿或太干燥。虽然顾客可能只讨论烹饪，从不讨论温度控制，但你应该认识到真正的波动性和幸福感，并将其融入到Wellbeing你的建筑组件中。

The real requirement for any house is to take care of the well-being of the occupants, not just their caloric intake. The house should not be too cold or too warm or too humid or too dry. While the customers may only discuss cooking and never discuss temperature control, you should recognize the real volatility, well-being, and encapsulate that in the Wellbeing component of your architecture.

由于大多数需求规范都充斥着伪装成需求的解决方案，因此功能分解绝对会最大化您的痛苦。您将永远追逐不断发展的解决方案，而永远不会认识到真正的潜在需求。

Since most requirements specifications are chock-full of solutions masquerading as requirements, functional decomposition absolutely maximizes your pain. You will forever be chasing the ever-evolving solutions, never recognizing the true underlying requirements.

需求规范中所有那些伪装成需求的解决方案其实都是因祸得福，因为您可以将家庭烹饪示例推广为一种真正的分析技术，用于发现波动性领域。首先指出伪装成需求的解决方案，然后询问是否还有其他可能的解决方案？如果有，那么真正的需求和潜在的波动性是什么？一旦确定了波动性，您必须确定解决该波动性的需求是真正的需求还是仍然是伪装成需求的解决方案。一旦你完成了所有解决方案的清理，剩下的很可能是基于波动性的分解的极佳候选者。

The fact that requirements specifications have all those solutions masquerading as requirements is actually a blessing in disguise because you can generalize the example of cooking in the house into a bona fide analysis technique for discovering areas of volatility. Start by pointing out the solutions masquerading as requirements, and ask if there are other possible solutions? If so, then what were the real requirements and the underlying volatility? Once you identify the volatility, you must determine if the need to address that volatility is a true requirement or is still a solution masquerading as a requirement. Once you have finished scrubbing away all the solutions, what you are left with are likely great candidates for volatility-based decomposition.

波动率列表

Volatilities List

在分解系统和创建架构之前，您应该简单地编制一份候选波动区域列表，作为需求收集和分析的自然组成部分。您应该以开放的心态对待这份列表。问问自己，沿着波动轴，什么可能会发生变化。识别伪装成需求的解决方案，并应用本章后面描述的其他技术。这份列表是跟踪您的观察结果和组织您的想法的强大工具。不要着手实际设计。您所做的只是维护一份列表。请注意，虽然系统设计不应超过几天，但识别正确的波动区域可能需要更长的时间。

Prior to decomposing a system and creating an architecture, you should simply compile a list of the candidate areas of volatility as a natural part of requirements gathering and analysis. You should approach the list with an open mind. Ask what could change along the axes of volatility. Identify solutions masquerading as requirements, and apply the additional techniques described later in this chapter. The list is a powerful instrument for keeping track of your observations and organizing your thoughts. Do not commit yet to the actual design. All you are doing is maintaining a list. Note that while the design of the system should not take more than a few days, identifying the correct areas of volatility may take considerably longer.

示例：基于波动率的交易系统

Example: Volatility-Based Trading System

使用先前对股票交易系统的要求，您应该首先准备一份可能出现波动的领域的清单，并了解每个波动背后的原因：

Using the previous requirements for the stock trading system, you should start by preparing a list of possible areas of volatility, capturing also the rationale behind each:

• 用户波动。交易员为最终客户提供服务，而他们负责管理这些客户的投资组合。最终客户也可能对他们的资金现状感兴趣。虽然他们可以给交易员写信或打电话，但更合适的方式是让最终客户登录系统查看当前余额和正在进行的交易。即使要求从未提及任何有关最终客户访问权限的内容（要求针对专业交易员），您也应该考虑这种访问权限。虽然最终客户可能无法进行交易，但他们应该能够查看其账户的状态。也可能有系统管理员。用户类型存在波动。

• User volatility. The traders serve end customers on whose portfolios they operate. The end customers are also likely interested in the current state of their funds. While they could write the trader a letter or call, a more appropriate means would be for the end customers to log into the system to see the current balance and the ongoing trades. Even though the requirements never stated anything about end customer access (the requirements were for professional traders), you should contemplate such access. While the end customers may not be able to trade, they should be able to see the status of their accounts. There could also be system administrators. There is volatility in the type of user.

• 客户端应用程序波动。用户的波动通常表现为客户端应用程序和技术类型的波动。一个简单的网页可能足以让外部终端客户查询他们的余额。然而，专业交易员更喜欢多显示器、丰富的桌面应用程序，其中包含市场趋势、账户详细信息、市场行情、新闻提要、电子表格预测和专有数据。其他用户可能希望在各种类型的移动设备上查看交易。

• Client application volatility. Volatility in users often manifests in volatility in the type of client application and technology. A simple web page may suffice for external end customers looking up their balance. However, professional traders will prefer a multi-monitor, rich desktop application with market trends, account details, market tickers, newsfeed, spreadsheet projection, and proprietary data. Other users may want to review the trades on mobile devices of various types.

• 安全性波动。用户的波动意味着用户在系统中验证身份的方式的波动。内部交易员的数量可能很少，从几十人到几百人不等。然而，该系统可能数百万终端客户。内部交易员可以依靠域帐户进行身份验证，但对于通过互联网访问信息的数百万客户来说，这是一个糟糕的选择。对于互联网用户来说，也许一个简单的用户名和密码就可以了，或者可能需要一些复杂的联合安全单点登录选项。授权选项也存在类似的波动性。安全性是不稳定的。

• Security volatility. Volatility in users implies volatility in how the users authenticate themselves against the system. The number of in-house traders could be small, from a few dozens to a few hundred. The system, however, could have millions of end customers. The in-house traders could rely on domain accounts for authentication, but this is a poor choice for the millions of customers accessing information through the Internet. For Internet users, perhaps a simple user name and password will do, or maybe some sophisticated federated security single sign-on option is needed. Similar volatility exists with authorization options. Security is volatile.

• 通知易变性。需求指定系统在每次请求后发送电子邮件。但是，如果电子邮件被退回怎么办？系统是否应该恢复使用纸质信件？用短信或传真代替电子邮件怎么样？发送电子邮件的需求是伪装成需求的解决方案。真正的需求是通知用户，但通知传输易变。接收通知的人也存在易变性：单个用户或向接收相同通知的多个用户广播并通过任何传输方式接收。也许最终客户更喜欢电子邮件，而最终客户的税务律师更喜欢书面纸质声明。首先发布通知的人也存在易变性。

• Notification volatility. The requirements specify that the system is to send an email after every request. However, what if the email bounces? Should the system fall back to a paper letter? How about a text message or a fax instead of an email? The requirement to send an email is a solution masquerading as a requirement. The real requirement is to notify the users, but the notification transport is volatile. There is also volatility in who receives the notification: a single user or a broadcast to several users receiving the same notification and over whichever transport. Perhaps the end customer prefers an email while the end customer’s tax lawyer prefers a documented paper statement. There is also volatility in who publishes the notification in the first place.

• 存储易变性。要求指定使用本地数据库。但是，随着时间的推移，越来越多的系统迁移到云中。股票交易本身并没有什么可以阻止从云的成本和规模经济中获益。使用本地数据库的要求实际上是另一种伪装成要求的解决方案。更好的要求是数据持久性，它可以适应持久性选项中的易变性。但是，大多数用户都是最终客户，这些用户实际上执行只读请求。这意味着系统将从使用内存缓存中受益匪浅。此外，一些云产品使用分布式内存哈希表，提供与传统基于文件的持久存储相同的弹性。要求数据持久性将排除这最后两个选项，因为数据持久性仍然是一种伪装成要求的解决方案。真正的要求只是系统不能丢失数据，或者系统需要存储数据。如何实现这一点是一个实施细节，具有很大的波动性，从本地数据库到云端的远程内存缓存。

• Storage volatility. The requirements specify the use of a local database. However, over time, more and more systems migrate to the cloud. There is nothing inherent in stock trading that precludes benefiting from the cost and economy of scale of the cloud. The requirement to use a local database is actually another solution masquerading as a requirement. A better requirement is data persistence, which accommodates the volatility in the persistence options. However, the majority of users are end customers, and those users actually perform read-only requests. This implies the system will benefit greatly from the use of an in-memory cache. Furthermore, some cloud offerings utilize a distributed in-memory hash table that offers the same resiliency as traditional file-based durable storage. Requiring data persistence would exclude these last two options because data persistence is still a solution masquerading as a requirement. The real requirement is simply that the system must not lose the data, or that the system is required to store the data. How that is accomplished is an implementation detail, with a great deal of volatility, from a local database to a remote in-memory cache in the cloud.

• 连接和同步不稳定。当前要求以连接、同步、锁步的方式填写 Web 表单并按顺序提交。这意味着交易员一次只能执行一个请求。但是，交易员执行的交易越多，他们赚的钱就越多。如果请求是独立的，为什么不异步发出它们？如果请求在时间上被推迟（未来的交易），为什么不将对系统的调用排队以减少负载？执行异步调用（包括排队调用）时，请求可能会无序执行。连接和同步性不稳定。

• Connection and synchronization volatility. The current requirements call for a connected, synchronous, lock-step manner of completing a web form and submitting it in-order. This implies that the traders can do only one request at a time. However, the more trades the traders execute, the more money they make. If the requests are independent, why not issue them asynchronously? If the requests are deferred in time (trades in the future), why not queue up the calls to the system to reduce the load? When performing asynchronous calls (including queued calls), the requests can execute out of order. Connectivity and synchronicity are volatile.

• 持续时间和设备波动。有些用户会在一次短暂的会话中完成交易。但是，交易者在进行分散和对冲风险的复杂交易时，可以赚取利润并实现收入最大化，这些交易涉及多个股票和行业、国内或国外市场等。构建这样的交易可能非常耗时，持续数小时到数天不等。这种长时间的交互可能会跨越多个系统会话，甚至可能是多个物理设备。交互持续时间存在波动，这反过来会触发所涉及的设备和连接的波动。

• Duration and device volatility. Some users will complete a trade in one short session. However, traders earn their keep and maximize their income when they perform complicated trades that distribute and hedge risk, involving multiple stocks and sectors, domestic or foreign markets, and so on. Constructing such a trade can be time-consuming, lasting anywhere from several hours to several days. Such a long-running interaction will likely span multiple system sessions and possibly multiple physical devices. There is volatility in the duration of the interaction, which in turn triggers volatility in the devices and connections involved.

• 贸易项目波动性。如前所述，随着时间的推移，最终客户可能不仅想交易股票，还想交易商品、债券、货币，甚至期货合约。贸易项目本身具有波动性。

• Trade item volatility. As discussed previously, over time, the end customers may want to trade not just stocks but also commodities, bonds, currencies, and maybe even future contracts. The trade item itself is volatile.

• 工作流程不稳定。如果交易项目不稳定，则交易所涉及的步骤的处理也会不稳定。买卖股票、安排订单等与出售商品、债券或货币有很大不同。因此，交易的工作流程不稳定。同样，交易分析的工作流程也是不稳定的。

• Workflow volatility. If the trade item is volatile, processing of the steps involved in the trade will be volatile too. Buying and selling stocks, scheduling their orders, and so on are very different from selling commodities, bonds, or currencies. The workflow of the trade is therefore volatile. Similarly, the workflow of trade analysis is volatile.

• 地区和法规的波动。随着时间的推移，系统可能会部署到不同的地区。地区的波动对交易规则、用户界面本地化、交易项目列表、税收和法规合规性有重大影响。地区和适用的法规都是不稳定的。

• Locale and regulations volatility. Over time, the system may be deployed into different locales. Volatility in the locale has drastic implications on the trading rules, UI localization, the listing of trade items, taxation, and regulatory compliance. The locale and the regulations that apply therein are volatile.

• 市场信息波动。市场数据的来源可能随时间而变化。各种信息有不同的格式、成本、更新率、通信协议等。不同的信息可能在同一时间点显示同一股票的略微不同的价值。信息可以是外部的（例如彭博或路透社）或内部的（例如用于测试、诊断或交易算法研究的模拟市场数据）。市场信息具有波动性。

• Market feed volatility. The source of market data could change over time. Various feeds have a different format, cost, update rate, communication protocols, and so on. Different feeds may show slightly different value for the same stock at the same point in time. The feeds can be external (e.g., Bloomberg or Reuters) or internal (e.g., simulated market data for testing, diagnostics, or trading algorithms research). The market feed is volatile.

系统分解

一旦确定了波动性区域，就需要将它们封装到架构的组件中。图 2-13描述了一种可能的分解。

Once you have settled on the areas of volatility, you need to encapsulate them in components of the architecture. One such possible decomposition is depicted in Figure 2-13.

从易变区域列表到架构组件的转换几乎从来都不是一对一的。有时，单个组件可以封装多个易变区域。某些易变区域可能不会直接映射到组件，而是映射到操作概念，例如排队或发布事件。在其他时候，区域的易变性可能封装在第三方服务中。

The transition from the list of volatile areas to components of the architecture is hardly ever one to one. Sometimes a single component can encapsulate more than one area of volatility. Some areas of volatility may not be mapped directly to a component but rather to an operational concept such as queuing or publishing an event. At other times, the volatility of an area may be encapsulated in a third-party service.

在设计时，始终从简单易行的决策开始。这些决策会约束系统，使后续决策更容易。在此示例中，某些映射很容易进行。数据存储中的易失性封装在数据访问组件后面，这些组件不会泄露存储的位置以及使用何种技术来访问它。请注意图 2-13中将存储称为Storage和不称为 的关键抽象Database。虽然实现（根据要求）是一个本地数据库，但架构中没有任何内容排除其他选项，例如原始文件系统、缓存或云。如果对存储进行了更改，则更改将封装在相应的访问组件（例如Trades Access）中，并且不会影响其他组件，包括任何其他访问组件。这使您能够以最小的后果更改存储。

With design, always start with the simple and easy decisions. Those decisions constrain the system, making subsequent decisions easier. In this example, some mapping is easy to do. The volatility in the data storage is encapsulated behind data access components, which do not betray where the storage is and what technology is used to access it. Note in Figure 2-13 the key abstraction of referring to the storage as Storage and not as Database. While the implementation (according to the requirements) is a local database, there is nothing in the architecture that precludes other options, such as the raw file system, a cache, or the cloud. If a change to the storage takes place, it is encapsulated in the respective access component (such as the Trades Access) and does not affect the other components, including any other access component. This enables you to change the storage with minimal consequences.

通知客户端的易变性封装在Notification组件中。该组件知道如何通知每个客户端以及哪些客户端订阅哪个事件。对于简单的场景，您可以使用通用事件发布和订阅服务 ( Pub/Sub ) 而不是自定义Notification组件进行充分管理。但是，在这种情况下，传输类型和广播性质可能存在一些业务规则。Notification组件可能仍会在其下方使用一些 Pub/Sub 服务，但这是一个内部实现细节，其易变性也封装在Notification组件中。

The volatility in notifying the clients is encapsulated in the Notification component. This component knows how to notify each client and which clients subscribe to which event. For simple scenarios, you can manage sufficiently with a general-purpose events publishing and subscription service (Pub/Sub) instead of a custom Notification component. However, in this case, there are likely some business rules on the type of transport and nature of the broadcast. The Notification component may still use some Pub/Sub service underneath it, but that is an internal implementation detail whose volatility is also encapsulated in the Notification component.

交易工作流中的波动性被封装在Trade Workflow组件中。该组件封装了交易商品（股票或货币）的波动性、买卖交易商品的具体步骤、当地市场所需的定制、所需报告的详细信息等等。请注意，即使交易商品是固定的（不易变），交易股票的工作流也可能发生变化，这证明了使用Trade Workflow封装波动性的合理性。该设计还依赖于存储工作流的操作概念（这应该使用某些第三方工作流工具来实现）。Trade Workflow检索每个会话的适当工作流实例，对其进行操作，然后将其存储回存储中Workflow。这个概念有助于封装多种波动性。首先，不同的交易商品现在可以拥有不同的交易工作流。其次，不同的语言环境可以拥有不同的工作流。第三，这可以支持跨多个设备和会话的长期运行工作流。系统不关心两个呼叫是相隔几秒还是几天。在每种情况下，系统都会加载工作流实例以处理下一步。该设计将连接的单会话交易与长期运行的分布式交易完全相同。对称性和一致性是系统架构的良好品质。还请注意，工作流存储访问的封装方式与交易存储访问的封装方式相同。

The volatility in the trading workflow is encapsulated in the Trade Workflow component. That component encapsulates the volatility of what is being traded (stocks or currencies), the specific steps involved in buying or selling a trade item, the required customization for local markets, the details for the required reports, and so on. Note that even if the trade items are fixed (not volatile), the workflow of trading stocks can change, justifying the use of Trade Workflow to encapsulate the volatility. The design also relies on the operational concept of storing the workflows (this should be implemented using some third-party workflow tool). Trade Workflow retrieves the appropriate workflow instance for each session, operates on it, and stores it back in the Workflow Storage. This concept helps encapsulate several volatilities. First, different trade items can now have distinct trading workflows. Second, different locales can have different workflows. Third, this enables supporting long-running workflows spanning multiple devices and sessions. The system does not care if two calls are seconds apart or days apart. In each case, the system loads the workflow instance to process the next step. The design treats connected, single-session trades exactly the same as a long-running distributed trade. Symmetry and consistency are good qualities in system architecture. Note also that the workflow storage access is encapsulated in the same fashion as the trades storage access.

您可以对股票交易工作流和分析工作流使用相同的模式。专用Analysis Workflow组件封装了分析工作流中的波动性，并且可以使用相同的Workflow Storage。

You can use the same pattern for the stock trading workflow and the analysis workflows. The dedicated Analysis Workflow component encapsulated the volatility in the analysis workflows, and it can use the same Workflow Storage.

访问市场 feed 的易变性封装在 中Feed Access。此组件封装了如何访问 feed 以及 feed 本身是内部的还是外部的。来自不同 feed 的各种市场数据的格式甚至值的易变性封装在 中Feed Transformation。这两个组件都通过提供统一的接口和格式（无论数据来源如何）将其他组件与 feed 分离。

The volatility of accessing the market feed is encapsulated in the Feed Access. This component encapsulates how to access the feed and whether the feed itself is internal or external. The volatility in the format or even value of the various market data coming from the different feeds is encapsulated in the Feed Transformation component. Both of these components decouple the other components from the feeds by providing a uniform interface and format regardless of the origin of the data.

该Security组件封装了对用户进行身份验证和授权的可能方式的易变性。在内部，它可能从本地存储中查找凭据或与某些分布式提供商进行交互。

The Security component encapsulates the volatility of the possible ways of authenticating and authorizing the users. Internally, it may look up credentials from a local storage or interact with some distributed provider.

系统的客户端可以是交易应用程序（Trader App A）或移动应用程序（Trader App B）。最终客户可以使用自己的网站（Customer Portal）。每个客户端应用程序还封装了详细信息以及在目标设备上呈现信息的最佳方式。

The clients of the system can be the trading application (Trader App A) or a mobile app (Trader App B). The end customers can use their own website (Customer Portal). Each client application also encapsulates the details and the best way of rendering the information on the target device.

笔记

Note

前面的讨论将易变性领域与架构进行了较为松散的映射。下一章将介绍结构和指导方针，使该过程更加确定。

The previous discussion performed a somewhat loose mapping of areas of volatility to architecture. The next chapter introduces structure and guidelines, making the process much more deterministic.

抵制诱惑

Resist The Siren Song

请注意，图 2-13中没有专用的报告组件。出于演示目的，报告未列为易变区域（从业务角度来看）。因此，没有什么可以用组件封装的。添加这样的组件体现了功能分解。但是，如果您只做过功能分解，您可能会听到一个不可抗拒的诱惑，召唤您添加报告块。仅仅因为您一直有一个报告块，甚至因为您有一个现有的报告块，并不意味着您需要一个报告块。

Note in Figure 2-13 the absence of a dedicated reporting component. For demonstration purposes, reporting was not listed as a volatile area (from the business perspective). Therefore, there is nothing to encapsulate with a component. Adding such a component manifests functional decomposition. However, if functional decomposition is all you have ever done, you will likely hear an irresistible siren song calling you to add a reporting block. Just because you always have had a reporting block, or even because you have an existing reporting block, does not mean you need a reporting block.

在荷马的《奥德赛》中，这个故事已有 2500 多年历史，奥德修斯经由塞壬海峡航行回家。塞壬是长着美丽翅膀的精灵般的生物，拥有天使般的声音。她们唱着一首无人能抗拒的歌声。水手们扑向她们的手臂，塞壬将人们淹死在水底并吃掉了他们。在感受到塞壬歌声的致命诱惑之前，奥德修斯（您，建筑师）被建议用蜂蜡堵住水手们（普通软件开发人员）的耳朵，并将他们绑在桨上。水手们的工作是划船（编写代码），他们甚至没有自由听塞壬的声音。另一方面，作为领导者的奥德修斯自己却没有堵住耳朵的奢侈（例如，也许您确实需要那个报告块）。奥德修斯将自己绑在船桅杆上，这样即使他想屈服于塞壬也无法做到（见图2-14，描绘了时期花瓶上的场景）。你是奥德修斯，基于挥发性的分解是你的桅杆。抵制你以前坏习惯的诱惑。

In Homer’s Odyssey, a story that is more than 2500 years old, Odysseus sails home via the Straights of the Sirens. The Sirens are beautiful winged fairy-like creatures who have the voices of angels. They sing a song that no man can resist. The sailors jump to their arms, and the Sirens drown the men under the waves and eat them. Before encountering the deadly allure of the Sirens’ songs, Odysseus (you, the architect) is advised to plug with beeswax the ears of his sailors (the rank and file software developers) and tie them to the oars. The sailors’ job is to row (write code), and they are not even at liberty to listen to the Sirens. Odysseus himself, on the other hand, as the leader, does not have the luxury of plugging his ears (e.g., maybe you do need that reporting block). Odysseus ties himself to the mast of the ship so that he cannot succumb to the Sirens even if he wanted to do so (see Figure 2-14, depicting the scene on a period vase). You are Odysseus, and volatility-based decomposition is your mast. Resist the siren song of your previous bad habits.

波动性与业务

Volatility And The Business

虽然必须封装易变区域，但并非所有可能发生变化的区域都应封装。换句话说，可能发生变化的事物不一定易变。一个典型的例子是业务性质，您不应试图封装业务性质。几乎所有业务应用程序都是为了满足业务或其客户的某些需求而存在的。但是，业务性质（以及每个应用程序的性质）往往相当稳定。一家在某个行业经营了很长时间的公司很可能会一直从事该行业。例如，联邦快递过去、现在和将来都从事运输和递送业务。虽然理论上联邦快递有可能进军医疗保健领域，但这种潜在的变化并不是您应该封装的内容。

While you must encapsulate the volatile areas, not everything that could change should be encapsulated. Put differently, things that could change are not necessarily volatile. A classic example is the nature of the business, and you should not attempt to encapsulate the nature of the business. With almost all business applications, the applications exist to serve some need of the business or its customers. However, the nature of the business, and by extension, each application, tends to be fairly constant. A company that has been in a business for a long time will likely stay in that business. For example, Federal Express has been, is, and will be in the shipment and delivery business. While in theory it is possible for Federal Express to branch into healthcare, such a potential change is not something you should encapsulate.

在系统分解过程中，您必须确定要封装的波动区域和不需要封装的区域（例如，业务性质）。有时，您最初很难区分它们。如果某些可能发生变化的东西确实是业务性质的一部分，则有两个简单的指标。第一个指标是可能的变化很少见。是的，它可能会发生，但发生的可能性非常低。第二个指标是，任何试图封装变更的尝试都只能做得很差。无论投入多少时间或精力，都无法以一种让你感到自豪的方式正确地封装该方面。

During system decomposition, you must identify both the areas of volatility to encapsulate and those not to encapsulate (e.g., the nature of the business). Sometimes, you will have initial difficulty in telling these apart. There are two simple indicators if something that could change is indeed part of the nature of the business. The first indicator is that the possible change is rare. Yes, it could happen, but the likelihood of it happening is very low. The second indicator is that any attempt to encapsulate the change can only be done poorly. No practical amount of investment in time or effort will properly encapsulate the aspect in a way of which you can be proud.

例如，考虑在一块土地上设计一栋简单的住宅。在未来的某个时候，房主可能会决定将房屋扩建为 50 层的摩天大楼。将这种可能的变化融入您的房屋设计中，会产生与典型住宅设计截然不同的设计。房屋地基不是浅模浇筑的地基，而是必须包括数十个摩擦塔，这些塔可能向下打入数百英尺以支撑建筑物的重量。这将使地基能够同时支撑单户住宅和摩天大楼。接下来，配电板必须能够分配数千安培的电流，并且可能需要房屋有自己的变压器。虽然自来水公司可以将水送到房子里，但您必须留出一个房间来放置大型水泵，以便将水推到 50 层楼。下水道管道必须能够处理 50 层楼的居民。您必须为单户住宅进行所有这些巨大的投资。

For example, consider designing a simple residential house on a plot of land. At some point in the future, the homeowner may decide to extend the home into a 50-story skyscraper. Encapsulating that possible change in your house design produces a very different design than that of your typical residential house design. Instead of a shallow form-poured foundation, the house foundation must include dozens of friction pylons, driven down to maybe hundreds of feet to support the weight of the building. This will allow the foundation to support both a single family residential and a skyscraper. Next, the power panel must be able to distribute thousands of amps and likely requires the house to have its own transformer. While the water company can bring water to the house, you must devote a room for a large water pump that can push the water up 50 floors. The sewer line must be able to handle 50 floors of inhabitants. You will have to do all that tremendous investment for a single-family home.

完工后，地基将囊括建筑物重量的变化，配电盘将囊括单户住宅和 50 层楼的需求，等等。然而，这两个指标现在都被违反了。首先，你所在城市每年有多少房主将他们的房子改建成摩天大楼？这种情况有多普遍？在一个拥有一百万户家庭的大都市区，这种情况可能每隔几年就会发生一次，因此这种变化非常罕见，甚至百万分之一的概率也只有一次。其次，你是否真的有足够的资金（最初分配给单户住宅的资金）来妥善执行所有这些囊括？一座塔架的成本可能比单户住宅的建筑成本还高。任何试图囊括未来向摩天大楼过渡的尝试都将是失败的，既无用也不划算。

When you are finished, the foundation will encapsulate the change to the weight of the building, the power panel will encapsulate the demands of both a single home and 50 stories, and so on. However, the two indicators are now violated. First, how many homeowners in your city annually do convert their home to a skyscraper? How common is that? In a large metropolitan area with a million homes, it may happen once every few years, making the change very rare, once in a million if that. Second, do you really have the funds (allocated initially for a single home) to properly execute all these encapsulations? A single pylon may cost more than the single-family building. Any attempt to encapsulate the future transition to a skyscraper will be done poorly and will be neither useful nor cost-effective.

将单户住宅改建为 50 层高的建筑是业务性质的改变。该建筑不再是用于家庭住房的业务。现在，它变成了酒店或办公楼。当土地开发商购买该地块用于此类改建时，开发商通常会选择拆除建筑，挖出旧地基，然后重新开始。业务性质的改变使您可以放弃旧系统并从头开始。需要注意的是，业务性质的背景在某种程度上是分形的。背景可以是公司的业务、公司部门或分部的业务，甚至可以是特定应用程序的业务附加值。所有这些都代表了您不应封装的内容。

Converting the single-family home to a 50-story building is a change to the nature of the business. No longer is the building in the business of housing a family. Now it is in the business of being a hotel or an office building. When a land developer purchases that plot of land for the purpose of such conversion, the developer usually chooses to raze the building, dig out the old foundation, and start afresh. A change to the nature of the business permits you to kill the old system and start from scratch. It is important to note that the context of the nature of the business is somewhat fractal. The context can be the business of the company, the business of a department or a division in a company, or even the business added value of a specific application. All these represent things that you should not encapsulate.

思辨设计

推测性设计是试图封装业务性质的一种变体。一旦你认同基于波动性的分解原则，你就会开始看到到处都存在可能的波动，而且很容易做得过头。如果走极端，你就有可能试图封装任何东西和所有地方。你的设计将有许多构建块，这是糟糕设计的明显标志。

Speculative design is a variation on trying to encapsulate the nature of the business. Once you subscribe to the principle of volatility-based decomposition, you will start seeing possible volatilities everywhere and can easily overdo it. When taken to the extreme, you run the risk of trying to encapsulate anything and everywhere. Your design will have numerous building blocks, a clear sign of a bad design.

例如，考虑图 2-15中的项目。

Consider for example the item in Figure 2-15.

该物品是一双适合潜水的女士高跟鞋。虽然身着精致晚礼服的女士可以穿着这双鞋在派对上招待客人，但她会不会马上离开，直接走到门廊，穿上潜水装备，然后潜入珊瑚礁呢？这双鞋和传统的高跟鞋一样优雅吗？在游泳或踩到尖锐的珊瑚时，它们和普通的脚蹼一样有效吗？虽然图 2-15中的物品是可以使用的，但可能性极小。此外，他们试图提供的一切都做得很差，因为他们试图将鞋子的性质从时尚配饰转变为潜水配饰，这是你永远不应该尝试的。如果你尝试这样做，你就掉进了投机性设计陷阱。大多数这样的设计只是对你的系统未来变化（即业务性质的变化）的轻率猜测。

The item is a pair of SCUBA-ready lady’s high heels. While a lady adorned in a fine evening gown could entertain her guests at the party wearing these, how likely is it that she will excuse herself, proceed immediately to the porch, draw on SCUBA gear, and dive into the reef? Are these shoes as elegant as conventional high heels? Are these as effective as regular flippers when it comes to swimming or stepping on sharp coral? While the use of the items in Figure 2-15 is possible, it is extremely unlikely. In addition, everything they try to provide is done very poorly because of the attempt to encapsulate a change to the nature of the shoe, from a fashion accessory to a diving accessory, something you should never attempt. If you try this, you have fallen into the speculative design trap. Most such designs are simply frivolous speculation on a future change to your system (i.e., a change to the nature of the business).

为你的竞争对手设计

Design For Your Competitors

识别波动性的另一种有用方法是尝试为你的竞争对手（或你公司的另一个部门）设计一个系统。例如，假设你是联邦快递下一代系统的首席架构师。您的主要竞争对手是 UPS。联邦快递和 UPS 都运送包裹。两者都收取资金、安排提货和送货、跟踪包裹、为包裹投保并管理卡车和飞机车队。问自己以下问题：联邦快递可以使用 UPS 正在使用的软件系统吗？UPS 可以使用联邦快递想要构建的系统吗？如果答案是否定的，请开始列出这种重用​​或可扩展性的所有障碍。虽然两家公司在抽象上提供相同的服务，但他们开展业务的方式却不同。例如，联邦快递可能以一种方式规划运输路线，而 UPS 可能以另一种方式规划。在这种情况下，运输规划可能不稳定，因为如果有两种方式做某事，那么可能会有更多方式。您必须封装运输规划并在您的架构中为此目的指定一个组件。如果联邦快递在未来某个时间开始以与 UPS 相同的方式规划运输，则更改现在包含在单个组件中，这使得更改变得容易，并且只影响该组件的实现，而不会影响分解。您已为您的系统做好了面向未来的准备。

Another useful technique for identifying volatilities is to try to design a system for your competitor (or another division in your company). For example, suppose you are the lead architect for Federal Express’s next-generation system. Your main competitor is UPS. Both Federal Express and UPS ship packages. Both collect funds, schedule pickup and delivery, track packages, insure content, and manage trucks and airplane fleets. Ask yourself the following question: Can Federal Express use the software system UPS is using? Can UPS use the system Federal Express wants to build? If the likely answer is no, start listing all the barriers for such a reuse or extensibility. While both companies perform in the abstract the same service, the way they conduct their business is different. For example, Federal Express may plan shipment routes one way, while UPS may plan them another. In that case, shipment planning is probably volatile because if there are two ways of doing something, there may be many more. You must encapsulate the shipment planning and designate a component in your architecture for that purpose. If Federal Express starts planning shipments the same as UPS at some future time, the change is now contained in a single component, making the change easy and affecting only the implementation of that component, not the decomposition. You have future-proofed your system.

相反的情况也是如此。如果您和您的竞争对手（甚至更好的是，所有竞争对手）以相同的方式执行某些活动或序列，并且您的系统不可能以任何其他方式执行，那么就没有必要在架构中为该活动分配组件。这样做会造成功能分解。当您遇到竞争对手做同样的事情时，很可能它代表了业务的性质，正如前面所讨论的那样，您不应该封装它。

The opposite case is also true. If you and your competitor (and even better, all competitors) do some activity or sequence the same way, and there is no chance of your system doing it any other way, then there is no need to allocate a component in the architecture for that activity. To do so would create a functional decomposition. When you encounter something your competitors do identically, more likely than not, it represents the nature of the business, and as discussed previously, you should not encapsulate it.

波动性和持久性

Volatility And Longevity

波动性与寿命密切相关。公司或应用程序以同样的方式做某事的时间越长，公司继续以同样的方式做事的可能性就越大。换句话说，事情越久不改变，它们改变或被取代的时间就越长。你必须提出一个能适应这种变化的设计，即使乍一看这种变化与当前的需求无关。

Volatility is intimately related to longevity. The longer the company or the application has been doing something the same way, the higher the likelihood the company will keep doing it the same way. Put differently, the longer things do not change, the longer they have until they do change or are replaced. You must put forward a design that accommodates such changes, even if at first glance such changes are independent of the current requirements.

您甚至可以使用简单的启发式方法估计这种变化可能发生的时间：组织（或客户或市场）发起或吸收变化的能力或多或少是恒定的，因为它与业务性质有关。例如，医院 IT 部门比新兴的区块链初创公司更保守，对变化的容忍度更低。因此，事物变化越频繁，未来变化的可能性就越大，但变化速度相同。例如，如果公司每 2 年更改一次工资单系统，则公司很可能会在 2025 年内更改工资单系统。未来 2 年。如果您设计的系统需要与工资系统接口，并且使用系统的时间跨度超过 2 年，那么您必须封装工资系统的波动性并计划包含预期的变化。您必须考虑工资系统变更的影响，即使从未明确要求您进行变更。您应该努力封装系统生命周期内发生的变化。如果预计的寿命为 5 到 7 年，那么一个好的起点是确定过去 7 年中应用程序领域发生的所有变化。类似的变化很可能会在类似的时间跨度内发生。

You can even guesstimate how long it will be until such a change is likely to take place using a simple heuristic: the ability of the organization (or the customer or the market) to instigate or absorb a change is more or less constant because it is tied to the nature of the business. For example, a hospital IT department is more conservative and has less tolerance for change than a nascent blockchain startup. Thus, the more frequently things change, the more likely they will change in the future, but at the same rate. For example, if every 2 years the company changes its payroll system, it is likely the company will change the payroll system within the next 2 years. If the system you design needs to interface with the payroll system and the horizon for using your system is longer than 2 years, then you must encapsulate the volatility in the payroll system and plan to contain the expected change. You must take into account the effect of a payroll system change even if the change was never given to you as an explicit requirement. You should strive to encapsulate changes that occur within the life of the system. If that projected lifespan is 5 to 7 years, a good starting point is identifying all the things that have changed in the application domain over the past 7 years. It is likely similar changes will occur within a similar timespan.

您应该以这种方式检查您的设计与之交互的所有相关系统和子系统的寿命。例如，如果企业资源规划 (ERP) 系统每 10 年更改一次，上次 ERP 更改是 8 年前，而新系统的期限为 5 年，那么 ERP 很可能会在系统的生命周期内发生变化。

You should examine this way the longevity of all involved systems and subsystems with which your design interacts. For example, if the enterprise resource planning (ERP) system changes every 10 years, the last ERP change was 8 years ago, and the horizon for your new system is 5 years, then it is a good bet the ERP will change during the life of your system.

练习的重要性

The Importance Of Practicing

如果你只花 2% 的时间在某件事上，那么无论你拥有怎样的智力或使用的方法，你都永远不会擅长这件事。要相信每隔几年就会有人能靠近白板，画几条线，然后确定架构，那需要多么惊人的狂妄自大。专业人士（无论是医生、飞行员、焊工还是律师）的基本期望是，他们要通过培训掌握自己的技能。你不会希望成为飞行员只有少量飞行时间的飞机上的乘客。你也不会希望成为医生的第一位病人。商业航空公司的飞行员要花费数年时间（复数）在模拟器上，并由经验丰富的飞行员通过数百次飞行进行培训。医生在接触第一位病人之前要解剖无数的尸体，即使这样，他们也受到严密的监督。

If you only spend 2% of the time on anything, you will never be any good at it, regardless of your built-in intellect or methodology used. An amazing level of hubris is required to believe that once every few years someone can approach a whiteboard, draw a few lines, and nail the architecture. The basic expectation of professionals, be they doctors, pilots, welders or lawyers, is that they master their craft by training for it. You would not wish to be the passenger aboard a plane where the pilot has only a handful of flying hours. You would not wish to be the first patient of a doctor. Commercial airline pilots spend years (plural) in simulators and are trained through hundreds of flights by veteran pilots. Doctors dissect countless cadavers before they can touch the first patient, and even then, they are closely supervised.

识别波动性领域是一项后天习得的技能。几乎没有任何软件架构师最初接受过基于波动性的分解培训，绝大多数系统和项目都使用功能分解（结果很糟糕）。掌握基于波动性的分解的最佳方法是实践。这是解决 2% 问题的唯一方法。以下是您可以开始的几种方法：

Identifying areas of volatility is an acquired skill. Hardly any software architect is initially trained in volatility-based decomposition, and the vast majority of systems and projects use functional decomposition (with abysmal results). The best way of going about mastering volatility-based decomposition is to practice. This is the only way to address the 2% problem. Here are several ways you can start:

• 在您熟悉的日常软件系统上练习，例如典型的保险公司、移动应用程序、银行或在线商店。

• Practice on an everyday software system with which you are familiar, such as your typical insurance company, a mobile app, a bank, or an online store.

• 检查一下你自己过去的项目。事后看来，你已经知道痛点是什么了。过去那个项目的架构是否在功能上完成了？事情真的发生了变化吗？这些变化的连锁反应是什么？如果你能概括这种波动性，你是否能够更好地应对这种变化？

• Examine your own past projects. In hindsight, you already know what the pain points were. Was that architecture of that past project done functionally? What things did change? What were the ripple effects of those changes? If you had encapsulated that volatility, would you have been able to deal with that change better?

• 看看你当前的项目。现在挽救它还不算太晚：它是否功能齐全？你能列出易变的领域并提出更好的架构吗？

• Look at your current project. It may not be too late to save it: Is it designed functionally? Can you list the areas of volatility and propose a superior architecture?

• 观察非软件系统，例如自行车、笔记本电脑、房屋，并从中找出波动的领域。

• Look at non-software systems such as a bicycle, a laptop, a house, and identify in those the areas of volatility.

然后重复做，再多做几次。反复练习。在分析了三到五个系统之后，你应该掌握了一般技巧。遗憾的是，学会识别波动区域并不是通过观察别人就能掌握的。你不能从书本上学会骑自行车。你必须骑上自行车（并摔倒）几次。基于波动性的分解也是如此。然而，在练习中摔倒总比在真实对象上做实验要好。

Then do it again and do it some more. Practice and practice. After you have analyzed three to five systems, you should get the general technique. Sadly, learning to identify areas of volatility is not something you get to master by watching others. You cannot learn to ride a bicycle from a book. You have to mount a bicycle (and fall) a few times. The same is true with volatility-based decomposition. It is, however, preferable to fall during practice than to experiment on live subjects.

必需的行为

Required Behaviors

用例是所需行为的表达，即系统需要如何完成某些工作并为业务增加价值。因此，用例是系统中活动的特定序列。用例往往冗长且具有描述性。它们可以描述最终用户与系统的交互，或系统与其他系统的交互，或后端处理。这种能力很重要，因为在任何设计良好的系统中，即使是中等规模和复杂度的系统，用户也只会与系统的一小部分进行交互或观察，这代表了冰山一角。系统的大部分仍处于水线以下，您也应该为其生成用例。

A use case is an expression of required behavior—that is, how the system is required to go about accomplishing some work and adding value to the business. As such, a use case is a particular sequence of activities in the system. Use cases tend to be verbose and descriptive. They can describe end-user interactions with the system, or the system’s interactions with other systems, or back-end processing. This ability is important because in any well-designed system, even one of modest size and complexity, the users interact with or observe just a small part of the system, which represents the tip of the iceberg. The bulk of the system remains below the waterline, and you should produce use cases for it as well.

您可以通过文本或图形捕获用例。文本用例易于生成，这是一个明显的优势。不幸的是，使用文本描述用例是一种较差的用例描述方式，因为用例可能过于复杂，无法以高保真度在文本中捕获。文本用例的真正问题是几乎没有人愿意阅读哪怕是简单的文本，这是有原因的。阅读对于人类大脑来说是一种人为的活动，因为大脑无法通过文本轻松吸收和处理复杂的想法。人类阅读已有 5000 年的历史——从进化的角度来说，阅读时间还不足以让大脑跟上（不过，感谢您为本书付出的努力）。

You can capture use cases either textually or graphically. Textual use cases are easy to produce, which is a distinct advantage. Unfortunately, using text for use cases is an inferior way of describing use cases because the use cases may be too complex to capture with high fidelity in text. The real problem with textual use cases is that hardly anyone bothers to read even simple text, and for a good reason. Reading is an artificial activity for the human brain, because the brain is not wired to easily absorb and process complex ideas via text. Mankind has been reading for 5000 years—not long enough for the brain to catch up, evolutionarily speaking (thank you for making the effort with this book, though).

捕捉用例的最佳方式是使用图表（图 3-1）。人类处理图像的速度非常快，因为人类大脑的近一半是一个巨大的视频处理单元。图表允许您利用这个处理器将想法传达给您的受众。

The best way of capturing a use case is graphically, with a diagram (Figure 3-1). Humans perform image processing astonishingly quickly, because almost half the human brain is a massive video processing unit. Diagrams allow you to take advantage of this processor to communicate ideas to your audience.

但是，图形化用例的制作非常耗费人力，尤其是大量用例时。许多用例可能足够简单，无需图表即可理解。例如，图 3-1中的用例图可以用文本同样好地表示。我的经验法则：嵌套的“if”的存在告诉您应该绘制用例。没有读者能够解析包含嵌套“if”的句子。相反，读者可能会不断重读用例，或者更有可能拿起笔和纸，尝试自己想象用例。通过这样做，读者正在解释行为 - 这也增加了误解的可能性。当读者在文本用例的一侧涂鸦时，您知道您应该首先提供可视化效果。图表还允许读者轻松理解复杂用例中大量嵌套的“if”。

Graphical use cases, however, can be very labor-intensive to produce, especially in large numbers. Many use cases may be simple enough to understand without a diagram. For example, the use case diagram in Figure 3-1 can be represented in text equally well. My rule of thumb: The presence of a nested “if” tells you that you should to draw the use case. No reader can parse a sentence containing a nested “if.” Instead, readers will likely continually reread the use case or, more likely, pick up a pen and paper and try to visualize the use case themselves. By doing so, readers are interpreting the behavior—which also raises the possibility of misinterpretation. When readers are scribbling on the side of your textual use case, you know you should have provided the visualization in the first place. Diagrams also allow readers to easily follow a larger number of nested “if”s in a complex use case.

活动图

方法更喜欢使用活动图¹来图形化表示用例，主要是因为活动图可以捕获行为的时间关键方面，这是流程图和其他图表无法做到的。您无法在流程图中表示并行执行、阻塞或等待某个事件发生。相比之下，活动图包含并发概念。例如，在图 3-2中，您可以直观地看到并行执行的处理是对事件的响应，甚至无需查看图表的符号指南。还请注意，遵循嵌套条件是多么容易。

The Method prefers activity diagrams¹ for graphical representation of use cases, primarily because activity diagrams can capture time-critical aspects of behavior, something that flowcharts and other diagrams are incapable of doing. You cannot represent parallel execution, blocking, or waiting for some event to take place in a flowchart. Activity diagrams, by contrast, incorporate a notion of concurrency. For example, in Figure 3-2, you intuitively see the handling of parallel execution as a response to the event without even seeing a notation guide for the diagram. Note also how easy it is to follow the nested condition.

1. https://en.wikipedia.org/wiki/Activity_diagram

1. https://en.wikipedia.org/wiki/Activity_diagram

警告

Caution

不要将活动图与用例图混淆。用例图^以用户为中心，应该称为用户用例图。用例图也不包含时间或顺序的概念。

Do not confuse activity diagrams with use case diagrams. Use case diagrams^a are user-centric and should have been called user case diagrams. Use case diagrams also do not include a notion of time or sequence.

a . https://en.wikipedia.org/wiki/Use_case_diagram

a. https://en.wikipedia.org/wiki/Use_case_diagram

使用服务

Using Services

跨层的首选方式是调用服务。虽然您当然可以从方法的结构和基于波动性的分解中获益，即使使用常规类，但依赖服务也具有明显的优势。使用哪种技术和平台来实现服务是次要问题。当您使用服务时（只要您选择的技术允许），您会立即获得以下好处：

The preferred way of crossing layers is by calling services. While you certainly can benefit from the structure of The Method and volatility-based decomposition even with regular classes, relying on services provides distinct advantages. Which technology and platform you use to implement your services is a secondary concern. When you do use services (as long as the technology you chose allows), you immediately gain the following benefits:

• 可扩展性。服务可以以多种方式实例化，包括按每次调用实例化。这允许大量客户端，而无需对后端资源施加成比例的负载，因为您只需要与正在进行的调用数量相同的服务实例。

• Scalability. Services can be instantiated in a variety of ways, including on a per-call basis. This allows for a very large number of clients without placing a proportional load on the back-end resources, as you need only as many service instances as there are calls in progress.

• 安全性。所有面向服务的平台都将安全性视为头等大事。因此，它们会对所有调用进行身份验证和授权 — 不仅是从客户端应用程序到服务的调用，还包括服务之间的调用。您甚至可以使用某种身份传播机制来支持信任链模式。

• Security. All service-oriented platforms treat security as a first-class aspect. Thus, they authenticate and authorize all calls—not just those from the client application to the services, but also those between services. You can even use some identity propagation mechanism to support a chain-of-trust pattern.

• 吞吐量和可用性。服务可以通过队列接受调用，只需将超额负载排队即可处理大量消息。排队调用还可以提高可用性，因为您可以让多个服务实例处理同一个传入队列。

• Throughput and availability. Services can accept calls over queues, allowing you to handle a very large volume of messages by simply queuing up the excess load. Queued calls also enable availability, because you can have multiple service instances process the same incoming queue.

• 响应能力。服务可以将调用限制到缓冲区以避免系统超负荷。

• Responsiveness. Services can throttle the calls into a buffer to avoid maxing out the system.

• 可靠性。客户端和服务可以使用一些可靠的消息传递协议来保证交付、处理网络连接问题，甚至排序调用。

• Reliability. Clients and services can use some reliable messaging protocol to guarantee delivery, handle network connectivity issues, and even order the calls.

• 一致性。所有服务都可以参与同一个工作单元，无论是在事务中（当由基础设施支持时），还是在最终一致的协调业务事务中。调用链上的任何错误都会导致整个交互中止，而无需根据错误的性质和恢复逻辑将服务耦合在一起。

• Consistency. The services can all participate in the same unit of work, either in a transaction (when supported by the infrastructure) or in a coordinated business transaction that is eventually consistent. Any error along the call chain causes the entire interaction to abort, without coupling the services along the nature of the error and the recovery logic.

• 同步。即使客户端使用多个并发线程，对服务的调用也可以自动同步。

• Synchronization. The calls to the service can be automatically synchronized even if the clients use multiple concurrent threads.

客户端层

The Client Layer

架构中的顶层是客户端层，也称为表示层。我觉得“表示”一词有些误导。“表示”意味着向人类用户呈现一些信息，好像这就是对顶层的全部期望。客户端层中的元素很可能是最终用户应用程序，但也可能是与您的系统交互的其他系统。这是一个重要的区别：通过将其称为客户端层，您可以平等对待所有可能的客户端，以相同的方式对待它们。所有客户端（无论是最终用户应用程序还是其他系统）都使用相同的系统入口点（任何优秀设计的一个重要方面），并遵守相同的访问安全性、数据类型和其他接口要求。这反过来又促进了重用和可扩展性，并允许更容易的维护，因为一个入口点的修复会以相同的方式影响所有客户端。

The top layer in architecture is the client layer, also known as the presentation layer. I find the term “presentation” to be somewhat misleading. “Presentation” implies some information is being presented to human users, as if that is all that is expected from the top layer. The elements in the client layer may very well be end-user applications, but they can also be other systems interacting with your system. This is an important distinction: By calling this the client layer, you equalize all possible clients, treating them in the same way. All Clients (whether end-user applications or other systems) use the same entry points to the system (an important aspect of any good design) and are subject to the same access security, data types, and other interfacing requirements. This, in turn, promotes reuse and extensibility and allows for easier maintenance, as a fix at one entry point affects all Clients the same way.

让客户端使用服务可以更好地将表示与业务逻辑分开。大多数面向服务的技术对于它们允许通过端点传输的数据类型非常严格。这限制了将客户端与服务耦合的能力，统一对待所有客户端，并且至少在理论上更容易添加不同类型的客户端。

Having the Clients consume services caters to better separation of presentation from business logic. Most service-oriented technologies are very strict about the types of data they allow over the endpoints. This limits the ability to couple the Clients to the services, treats all Clients uniformly, and makes adding different types of Clients, at least in theory, easier to accomplish.

客户端层还封装了客户端中的潜在波动性。您的系统现在和将来在波动性方面可能拥有不同的客户端，例如桌面应用程序、Web 门户、移动应用程序、全息图和增强现实、API、管理应用程序等。各种客户端应用程序将使用不同的技术，以不同的方式部署，拥有自己的版本和生命周期，并且可能由不同的团队开发。事实上，客户端层通常是典型软件系统中最不稳定的部分。但是，所有这些波动性都封装在客户端层的各个块中，并且一个组件中的更改不会影响另一个客户端组件。

The client layer also encapsulates the potential volatility in Clients. Your system now and in the future across the axes of volatility may have different Clients such as desktop applications, web portals, mobile apps, holograms and augmented reality, APIs, administration applications, and so on. The various Client applications will use different technologies, be deployed differently, have their own versions and life cycles, and may be developed by different teams. Indeed, the client layer is often the most volatile part of a typical software system. However, all of that volatility is encapsulated in the various blocks of the client layer, and changes in one component do not affect another Client component.

业务逻辑层

The Business Logic Layer

业务逻辑层封装了系统业务逻辑中的易变性。此层实现系统所需的行为，如前所述，这些行为最好在用例中表达。如果用例是静态的，那么就不会有需要业务逻辑层。然而，用例在客户和时间上都是不稳定的。由于用例包含系统中的一系列活动，因此特定用例只能以两种方式更改：要么序列本身发生变化，要么用例内的活动发生变化。例如，考虑图 3-1中的用例与图 3-5中的用例。

The business logic layer encapsulates the volatility in the system’s business logic. This layer implements the system’s required behavior, which, as mentioned previously, is best expressed in use cases. If the use cases were static, there would be no need for a business logic layer. Use cases, however, are volatile, across both customers and time. Since a use case contains a sequence of activities in the system, a particular use case can change in only two ways: Either the sequence itself changes or the activities within the use case change. For example, consider the use case in Figure 3-1 versus the use cases in Figure 3-5.

图 3-1和3-5中的所有四个用例都使用相同的活动A、B和C，但每个序列都是唯一的。这里的关键观察是工作流的顺序或编排可以独立于活动而改变。

All four use cases in Figures 3-1 and 3-5 use the same activities A, B, and C, but each sequence is unique. The key observation here is that the sequence or the orchestration of the workflow can change independently from the activities.

现在考虑图 3-6中的两个活动图。它们都调用完全相同的序列，但它们使用不同的活动。活动可以独立于序列而改变。

Now consider the two activity diagrams in Figure 3-6. Both call for exactly the same sequence, but they use different activities. The activities can change independently from the sequence.

序列和活动都是不稳定的，在方法中，这些不稳定被封装在称为管理器和引擎的特定组件中。管理器组件封装序列中的不稳定，而引擎组件封装活动中的不稳定。在第 2 章的股票交易分解示例中，Trade Workflow组件（见图2-13）是管理器，而Feed Transformation组件是引擎。

Both the sequence and the activities are volatile, and in The Method these volatilities are encapsulated in specific components called Managers and Engines. Manager components encapsulate the volatility in the sequence, whereas Engine components encapsulate the volatility in the activity. In Chapter 2, in the stock trading decomposition example, the Trade Workflow component (see Figure 2-13) is a Manager, while the Feed Transformation component is an Engine.

由于用例通常是相关的，管理器倾向于封装一系列逻辑相关的用例，例如特定子系统中的用例。例如，对于第 2 章的股票交易系统，Analysis Workflow有一个单独的管理器 来自Trade Workflow，每个管理器都有一组相关的用例要执行。引擎的范围更受限制，并封装了业务规则和活动。

Since use cases are often related, Managers tend to encapsulate a family of logically related use cases, such as those in a particular subsystem. For example, with the stock trading system of Chapter 2, Analysis Workflow is a separate Manager from Trade Workflow, and each Manager has its own related set of use cases to execute. Engines have more restricted scope and encapsulate business rules and activities.

由于序列中可以有很大的波动性，而序列中的活动却没有任何波动性（见图3-5），因此管理器可以使用零个或多个引擎。引擎可以在管理器之间共享，因为您可以代表一个管理器在一个用例中执行活动，然后在单独的用例中为另一个管理器执行相同的活动。您应该在设计引擎时考虑重用。但是，如果两个管理器使用两个不同的引擎来执行相同的活动，那么您要么需要进行功能分解，要么会忽略一些活动的波动性。您将在本章后面看到有关管理器和引擎的更多信息。

Since you can have great volatility in the sequence without any volatility in the activities of the sequence (see Figure 3-5), Managers may use zero or more Engines. Engines may be shared between Managers because you could perform an activity in one use case on behalf of one Manager and then perform the same activity for another Manager in a separate use case. You should design Engines with reuse in mind. However, if two Managers use two different Engines to perform the same activity, you either have functional decomposition on your hands or you have missed some activity volatility. You will see more on Managers and Engines later in this chapter.

资源访问层

The Resourceaccess Layer

资源访问层恰如其名，它封装了访问资源的易变性，此层中的组件称为ResourceAccess。例如，如果资源是数据库，则有数十种方法可用于访问数据库，并且没有一种方法在各个方面都优于所有其他方法。随着时间的推移，您可能希望更改访问数据库的方式，因此应该封装所涉及的更改或易变性。请注意，您不应简单地封装访问资源的易变性；也就是说，您还必须封装资源本身的易变性，例如本地数据库与基于云的数据库，或内存存储与持久存储。资源更改也必然会更改ResourceAccess。

The aptly named resource access layer encapsulates the volatility in accessing a resource, and the components in this layer are called ResourceAccess. For example, if the resource is a database, literally dozens of methods are available for accessing a database, and no single method is superior to all other methods in every respect. Over time, you may want to change the way you access the database, so that change or the volatility involved should be encapsulated. Note that you should not simply encapsulate the volatility in accessing the resource; that is, you must also encapsulate the volatility in the resource itself, such as a local database versus a cloud-based database, or in-memory storage versus durable storage. Resource changes invariably change ResourceAccess as well.

虽然资源访问层背后的动机显而易见，并且许多系统都包含某种形式的访问层，但大多数此类层最终都会通过创建类似于 I/O 操作或 CRUD 的ResourceAccess契约而暴露底层的波动性。例如，如果您的ResourceAccess服务契约包含Select()、Insert()和等操作Delete()，则底层资源很可能是数据库。如果您稍后将数据库更改为基于云的分布式哈希表，那么该数据库访问类契约将变得毫无用处，并且需要新的契约。更改契约会影响使用ResourceAccess组件的每个引擎和管理器。同样，您必须避免、、、和等操作，因为这些操作会将底层资源暴露为文件。设计良好的ResourceAccess组件会在其契约中公开围绕资源的原子业务动词。Open()Close()Seek()Read()Write()

While the motivation behind the resource access layer is readily evident and many systems incorporate some form of an access layer, most such layers end up exposing the underlying volatility by creating a ResourceAccess contract that resembles I/O operations or that is CRUD-like. For example, if your ResourceAccess service contract contains operations such as Select(), Insert(), and Delete(), the underlying resource is most likely a database. If you later change the database to a distributed cloud-based hash table, that database-access-like contract will become useless, and a new contract is required. Changing the contract affects every Engine and Manager that has used the ResourceAccess component. Similarly, you must avoid operations such as Open(), Close(), Seek(), Read(), and Write() that betray the underlying resource as being a file. A well-designed ResourceAccess component exposes in its contract the atomic business verbs around a resource.

资源层

The Resource Layer

资源层包含系统所依赖的实际物理资源，例如数据库、文件系统、缓存或消息队列。在方法中，资源可以是系统内部的，也可以是系统外部的。通常，资源本身就是一个完整的系统，但对于您的系统来说，它只是一个资源。

The resource layer contains the actual physical Resources on which the system relies, such as a database, file system, a cache, or a message queue. In The Method, the Resource can be internal to the system or outside the system. Often, the Resource is a whole system in its own right, but to your system it appears as just a Resource.

实用工具栏

Utilities Bar

图 3-4右侧的实用程序垂直栏包含实用程序服务。这些服务是几乎所有系统运行所需的某种形式的通用基础设施。实用程序可能包括、、、、、等等。您将在本章后面看到，与其他组件相比，实用程序需要不同的规则。SecurityLogging, DiagnosticsInstrumentationPub/SubMessage BusHosting

The utilities vertical bar on the right side of Figure 3-4 contains Utility services. These services are some form of common infrastructure that nearly all systems require to operate. Utilities may include Security, Logging, Diagnostics, Instrumentation, Pub/Sub, Message Bus, Hosting, and more. You will see later in this chapter that Utilities require different rules compared with the other components.

名字意味着什么

What’s in a Name

服务名称和图表对于向他人传达您的设计非常重要。描述性名称在业务和资源访问层中非常重要，因此The Method建议使用以下约定来命名它们：

Service names as well as diagrams are important in communicating your design to others. Descriptive names are so important within the business and resource access layers that The Method recommends the following conventions for naming them:

• 服务名称必须是用 Pascal 大小写书写的两部分复合词。

• Names of services must be two-part compound words written in Pascal case.

• 名称的后缀始终是服务的类型 — 例如Manager、Engine或Access（对于ResourceAccess）。

• The suffix of the name is always the service’s type—for example, Manager, Engine, or Access (for ResourceAccess).

• 前缀根据服务类型的不同而不同。

  – 对于经理，前缀应该是与用例中封装的波动性相关的名词。

  –  对于引擎，前缀应该是描述封装活动的名词。

  – 对于ResourceAccess，前缀应该是与Resource相关的名词，例如服务向消费用例提供的数据。

• The prefix varies with the type of service.

  –  For Managers, the prefix should be a noun associated with the encapsulated volatility in the use cases.

  –  For Engines, the prefix should be a noun describing the encapsulated activity.

  –  For ResourceAccess, the prefix should be a noun associated with the Resource, such as data that the service provides to the consuming use cases.

• 动名词（动名词是在动词上添加“ing”而形成的名词）应仅在引擎中用作前缀。在业务层或访问层的其他位置使用动名词通常表示功能分解。

• Gerunds (a gerund is a noun created by tacking “ing” onto a verb) should be used as a prefix only in with Engines. The use of gerunds elsewhere in the business or access layers usually signals functional decomposition.

• 原子业务动词不应用作服务名称的前缀。这些动词应仅限于与资源访问层交互的契约中的操作名称。

• Atomic business verbs should not be used in a prefix for a service name. These verbs should be confined to operation names in contracts interfacing with the resource access layer.

例如，在银行设计中，AccountManager和AccountAccess是可接受的服务名称。但是，名称BillingManager和BillingAccess功能分解的味道，因为动名词前缀传达的是“做”的概念，而不是编排或访问波动性。CalculatingEngine是一个很好的候选名称，因为引擎“做”诸如聚合、调整、制定战略、验证、评级、计算、转换、生成、调节、翻译、定位和搜索之类的事情。AccountEngine相比之下，名称没有任何活动波动性的指标，并且再次带有强烈的功能或域分解的味道。

As examples, in a bank design, AccountManager and AccountAccess are acceptable service names. However, the names BillingManager and BillingAccess smell of functional decomposition because the gerund prefixes convey a concept of “doing” rather than of an orchestration or access volatility. CalculatingEngine is a good candidate name because Engines “do” things such as aggregate, adapt, strategize, validate, rate, calculate, transform, generate, regulate, translate, locate, and search. The name AccountEngine, by contrast, is devoid of any indicator of the activity volatility and again carries a strong smell of functional or domain decomposition.

四个问题

The Four Questions

架构中的服务和资源层松散地对应于“谁”、“什么”、“如何”和“哪里”四个英语问题。“谁”与系统交互在客户端中，“什么”对系统有要求在管理器中，“如何”系统执行业务活动在引擎中，“如何”系统访问资源在资源访问中，“哪里”系统状态在资源中（见图3-7）。

The layers of services and resources in the architecture loosely correspond to the four English questions of “who,” “what,” “how,” and “where.” “Who” interacts with the system is in the Clients, “what” is required of the system is in Managers, “how” the system performs business activities is in Engines, “how” the system accesses Resources is in ResourceAccess, and “where” the system state is in Resources (see Figure 3-7).

这四个问题大致对应各个层级，因为波动性高于一切。例如，如果“如何”的波动性很小或没有波动性，那么管理者可以同时执行“什么”和“如何”。

The four questions loosely correspond to the layers because volatility trumps everything. For example, if there is little or no volatility in the “how,” the Managers can perform both “what” and “how.”

提出并回答这四个问题对于设计工作的启动和验证都很有用。如果您只有一张白纸，不知道从哪里开始，您可以通过回答这四个问题来启动设计工作。列出所有“谁”，并将它们作为客户的候选放入一个箱子中。列出所有“什么”，并将它们作为经理的候选放入另一个箱子中，依此类推。结果不会是完美的——例如，所有“什么”组件不一定都会合并成单个经理——但这是一个开始。

Asking and answering the four questions is useful at both ends of the design effort, for initiation and for validation. If all you have is a clean slate and no clear idea where to start, you can initiate the design effort by answering the four questions. Make a list of all the “who” and put them in one bin as candidates for Clients. Make a list of all the “what” and put them in another bin as candidates for Managers, and so on. The result will not be perfect—for example, all “what” components will not necessarily coalesce into individual Managers—but it is a start.

完成设计后，请退一步检查设计。您的所有客户都是“谁”，其中没有“什么”的痕迹吗？所有经理都是“什么”，其中没有一丝“谁”和“哪里”吗？同样，问题到层的映射并不完美。在某些情况下，您可能会在问题之间出现交叉。但是，如果您确信波动性的封装是合理的，则没有理由进一步怀疑该选择。如果您不相信，这些问题可能表明存在危险信号并需要进行调查。

Once you complete your design, take a step back and examine the design. Are all your Clients “who,” with no trace of “what” in them? Are all the Managers “what,” without a smidgen of “who” and “where” in them? Again, the mapping of questions to layers will not be perfect. In some cases, you could have crossover between questions. However, if you are convinced the encapsulation of the volatility is justified, there is no reason to doubt that choice further. If you are unconvinced, the questions could indicate a red flag and a decomposition to investigate.

这四个问题与之前关于命名服务的指导原则完美契合。如果Manager前缀描述了封装的易变性，那么用“什么”而不是动词“如何”来谈论它们会更自然。如果Engine前缀是描述封装活动的动名词，那么用“如何”而不是“什么”或“哪里”来谈论它们会更自然。出于类似的原因，ResourceAccess封装了“如何”来访问其背后的资源。

The four questions tie in nicely with the previous guideline on naming the services. If the Manager prefixes describe the encapsulated volatilities, it is more natural to talk about them in terms of “what” as opposed to the verb-like “how.” If the Engine prefixes are gerunds describing the encapsulated activities, it is more natural to talk about them in terms of “how” as opposed to “what” or “where.” For similar reasons, ResourceAccess encapsulates “how” to access the Resources that lie behind it.

管理人员与发动机的比例

Managers-to-Engines Ratio

大多数设计最终所包含的引擎数量都比您最初想象的要少。首先，要使引擎存在，必须有一些基本的操作波动性需要您封装 — 即未知数量的做事方式。这种波动性并不常见。如果您的设计包含大量引擎，您可能无意中进行了功能分解。

Most designs end up with fewer Engines than you might initially imagine. First, for an Engine to exist, there must be some fundamental operational volatility that you should encapsulate—that is, an unknown number of ways of doing something. Such volatilities are uncommon. If your design contains a large number of Engines, you may have inadvertently done a functional decomposition.

在 IDesign 的工作中，我们观察到许多系统中管理器和引擎往往保持黄金比例。如果您的系统只有一个管理器（不是神服务），那么您可能没有引擎，或者最多只有一个引擎。想想看：如果系统非常简单，一个像样的管理器就足够了，那么活动波动性高但用例类型不多的可能性有多大？

In our work at IDesign, we have observed across numerous systems that Managers and Engines tend to maintain a golden ratio. If your system has only one Manager (not a god service), you may have no Engines, or at most one Engine. Think about it: If the system is so simple that one decent Manager suffices, how likely is it to have high volatility in the activities but not that many types of use cases?

一般来说，如果您的系统有两个Manager，则很可能需要一个Engine。如果您的系统有三个Manager，则两个Engine可能是最佳数量。如果您的系统有五个Manager，则可能需要多达三个Engine。如果您的系统有八个Manager，则您已经无法进行良好的设计：大量的Manager强烈表明您进行了功能或领域分解。大多数系统永远不会有那么多Manager，因为它们不会有许多真正独立的、具有自身波动性的用例系列。此外，一个Manager可以支持多个用例系列，通常表示为不同的服务契约或服务的各个方面。这可以进一步减少系统中的Manager数量。

Generally, if your system has two Managers, you will likely need one Engine. If your system has three Managers, two Engines is likely the best number. If your system has five Managers, you may need as many as three Engines. If your system has eight Managers, then you have already failed to produce a good design: The large number of Managers strongly indicates you have done a functional or domain decomposition. Most systems will never have that many Managers because they will not have many truly independent families of use cases with their own volatility. In addition, a Manager can support more than one family of use cases, often expressed as different service contracts, or facets of the service. This can further reduce the number of Managers in a system.

主要观察

Key Observations

有了方法论的建议，您可以对精心设计的系统所具有的品质进行一些全面的观察。偏离这些观察结果可能表明功能分解仍在继续，或者至少分解不成熟，您只捕获了一些明显的波动，而忽略了其他波动。

Armed with the recommendations of The Method, you can make some sweeping observations about the qualities you expect to see in a well-designed system. Deviating from these observations may indicate a lingering functional decomposition or at least an unripe decomposition in which you have encapsulated few of the glaring volatilities but have missed others.

增量施工

Incremental Construction

如果系统相对简单且规模较小，则系统的业务价值（即用例的执行）可能需要架构的所有组件。对于这样的系统，只发布Engines或ResourceAccess组件是没有意义的。

If the system is relatively simple and small, the business value of the system—that is, the execution of the use cases—will likely require all components of the architecture. For such systems, there is no sense in releasing, say, just the Engines or the ResourceAccess components.

对于大型系统，某些子系统（如图3-8中的垂直切片）可能独立存在并提供直接的商业价值。此类系统的构建成本更高，完成时间更长。在这种情况下，分阶段开发和交付系统（一次一个切片）是合理的，而不是在项目结束时提供单一版本。此外，客户将能够就增量版本向开发人员提供早期反馈，而不是在最后才提供完整的系统。

With a large system, it could be that certain subsystems (such as the vertical slices of Figure 3-8) can stand alone and provide direct business value. Such systems will be more expensive to build and take longer to complete. In such cases it makes sense to develop and deliver the system in stages, one slice at a time, as opposed to providing a single release at the end of the project. Moreover, the customer will be able to provide early feedback to the developers on the incremental releases as opposed to only the complete system at the end.

无论是小型还是大型系统，正确的构建方法是另一条普遍原则：

With both small and large systems, the right approach to construction is another universal principle:

迭代设计，逐步构建。

Design iteratively, build incrementally.

无论领域和行业如何，这一原则都是正确的。例如，假设您希望在购买的一块土地上建造房屋。即使是最好的建筑师也无法在一次会议中为您的房屋设计出设计方案。在定义问题并讨论资金、居住者、风格、时间和风险等约束条件时，会有一些反复。您将从对蓝图的一些粗略修改开始，然后对其进行改进，评估其影响并研究替代方案。经过几次这样的迭代，设计将趋于一致。到了建造房屋的时候，您也会迭代地这样做吗？您会从双人帐篷开始，然后将其扩展到四人帐篷，然后是小棚屋，然后是小房子，最后是更大的房子吗？甚至考虑这种方法都是疯狂的。相反，您可能会挖掘和浇筑地基，然后将墙壁竖到一楼，然后将公用设施连接到结构，然后添加二楼，最后添加屋顶。简而言之，您可以逐步建造一座简单的房子。对于未来的房主来说，仅仅拥有地基或屋顶是没有任何价值的。也就是说，房子就像一个逐步建造的简单软件系统一样，在完成之前没有真正的价值。但是，如果建筑物有多个楼层（或多个翼楼），则可以逐步建造并提供中间价值。您的设计可能允许您一次完成一层（或一次完成一个翼楼），类似于大型软件系统的“一次一片”方法。

This principle is true regardless of domain and industry. For example, suppose you wish to build your house on a plot of land you have purchased. Even the best architect will not be able to produce the design for your house in a single session. There will be some back-and-forth as you define the problem and discuss constraints such as funds, occupants, style, time, and risk. You will start with some rough cuts to the blueprints, refine them, evaluate the implications, and examine alternatives. After several of these iterations, the design will converge. When it is time to build the house, will you do that iteratively, too? Will you start with a two-person tent, grow it out to a four-person tent, then to a small shed, then to a small house, and finally to a bigger house? It would be insane to even contemplate such an approach. Instead, you are likely to dig and cast the foundation, then erect the walls to the first floor, then connect utilities to the structure, then add the second floor, and finally add the roof. In short, you build a simple house incrementally. There is no value for the prospective homeowner in having just the foundations or the roof. That is, the house—like an incrementally built simple software system—has no real value until complete. However, if the building has multiple floors (or multiple wings), it may be possible to build it incrementally and deliver intermediate value. Your design may allow you to complete one floor at a time (or one wing at a time), similar to the “one slice at a time” approach to a large software system.

另一个例子是组装汽车。虽然汽车公司可能有一个设计团队设计汽车，经过多次迭代，但到了制造汽车的时候，制造过程并不是从滑板开始，然后发展成踏板车、自行车、摩托车，最后是汽车。相反，汽车是逐步制造的。首先，工人将底盘焊接在一起，然后用螺栓固定发动机缸体，然后添加座椅、外壳和轮胎。他们给汽车上漆，添加仪表板，最后安装内饰。

Another example is assembling cars. While the car company may have had a team of designers designing a car across multiple iterations, when it is time to build the car, the manufacturing process does not start with a skateboard, grow that to a scooter, then a bicycle, then a motorcycle, and finally a car. Instead, a car is built incrementally. First, the workers weld a chassis together, then they bolt on the engine block, and then they add the seats, the skin, and the tires. They paint the car, add the dashboard, and finally install the upholstery.

有两个原因导致你只能逐步构建，而不能迭代构建。首先，迭代构建非常浪费且困难（将摩托车变成汽车比仅仅制造汽车困难得多）。其次，更重要的是，中间迭代没有任何商业价值。如果客户想要一辆汽车送孩子上学，那么客户要一辆摩托车做什么呢？为什么客户要为此付钱？

There are two reasons why you can build only incrementally, and not iteratively. First, building iteratively is horrendously wasteful and difficult (turning a motorcycle into a car is much more difficult than just building a car). Second, and much more importantly, the intermediate iterations do not have any business value. If the customer wants a car to take the kids to school, what would the customer do with a motorcycle and why should the customer pay for it?

分阶段建造还可以让您适应时间和预算的限制。如果您设计了一栋四层楼的梦想之家，但您只能负担得起一栋单层楼的房子，那么您有两个选择。第一个选择仍然是用单层楼的预算建造一栋四层楼的房子，使用胶合板做所有墙壁，用塑料板做窗户，用水桶做浴室，用泥土做地板，用茅草做屋顶。第二个选择是只好好建造四层楼房子的一楼。当您积累了额外的资金时，您就可以建造二楼和三楼。十年后，当您最终完成建筑时，该建筑仍然与原始建筑相匹配。

Building incrementally also allows you to accommodate constraints on your time and budget. If you design a four-story dream house but you can afford only a single-floor house, you have two options. The first option is still build a four-story house with a single-floor budget by using plywood for all walls, sheet plastic for windows, buckets for a bathroom, dirt for floors, and a thatched roof. The second option is to properly build just the first floor of the four-story house. When you accumulate additional funds, you can then construct the second and third floors. A decade later, when you finally complete the building, that construction still matches the original architecture.

在架构范围内逐步构建的能力取决于架构的恒定性和真实性。使用功能分解，您将面对不断变化的碎片堆。可以公平地假设，那些只知道功能分解的人注定要进行迭代构建。使用基于波动性的分解，您有机会做对。

The ability to build incrementally over time, within the confines of the architecture, is predicated on the architecture remaining constant and true. With functional decomposition, you face ever-shifting piles of debris. It is fair to assume that those who know only functional decomposition are condemned to iterative construction. With volatility-based decomposition, you have a chance of getting it right.

关于微服务

About Microservices

我被誉为微服务的先驱之一。早在 2006 年，我就在演讲和写作中呼吁构建每个类都是一个服务的系统。2、3^{这需要使用}一种能够支持如此精细的服务的使用。我当时扩展了 Windows Communication Foundation (WCF) 来做到这一点，将每个类都视为服务，同时保持类的传统编程模型。4^我从来没有把这些服务称为“微服务”。那时和现在一样，我也不认为微服务概念存在。没有微服务，只有服务。例如，我车上的水泵为我的车提供了一项关键服务，而这个水泵只有 8 英寸长。当地自来水公司用来向我所在城镇供水的水泵为该镇提供了一项非常有价值的服务，但它有 8 英尺长。更大的水泵的存在并不会突然把我车上的水泵变成微型水泵：它仍然只是一个水泵。服务就是服务，无论其大小。要理解微服务这一人造概念的起源，您必须反思面向服务的历史。

I am credited as one of the pioneers of microservices. As early as 2006, in my speaking and writing I called for building systems in which every class was a service.^2,3 This requires the use of a technology that can support such granular use of services. I extended Windows Communication Foundation (WCF) at the time to do just that, taking every class and treating it as a service while maintaining the conventional programming model of classes.⁴ I never called these services “microservices.” Then, as now, I did not think the microservices concept existed. There are no microservices—only services. For example, the water pump in my car provides a critical service to my car, and that pump is only 8 inches long. The water pump that the local water company uses to push water to my town provides the town with a very valuable service, but it is 8 feet long. The existence of a larger pump does not suddenly transform the pump in my car into a micropump: It is still just a pump. Services are services regardless of their size. To understand the origin of the artificial concept of microservices, you have to reflect on the history of service-orientation.

2. https://wikipedia.org/wiki/Microservices#History

2. https://wikipedia.org/wiki/Microservices#History

3. Juval Löwy，《编程 WCF 服务》，第 1 版。（O'Reilly Media，2007 年），543–553。

3. Juval Löwy, Programming WCF Services, 1st ed. (O’Reilly Media, 2007), 543–553.

4. Löwy，《WCF 服务编程》，第 1 版，第 48-51 页；Juval Löwy，《WCF 服务编程》，第 3 版（O'Reilly Media，2010 年），第 74-75 页。

4. Löwy, Programming WCF Services, 1st ed., pp. 48–51; Juval Löwy, Programming WCF Services, 3rd ed. (O’Reilly Media, 2010), 74–75.

开放式架构

Open Architecture

在开放式架构中，任何组件都可以调用任何其他组件，无论组件位于哪一层。组件可以随意向上、向外和向下调用。开放式架构提供了最大的灵活性。然而，开放式架构通过牺牲封装性和引入大量耦合来实现这种灵活性。

In an open architecture, any component can call any other component regardless of the layer in which the components reside. Components can call up, sideways, and down as much as you like. Open architectures offer the ultimate flexibility. However, an open architecture achieves that flexibility by sacrificing encapsulation and introducing a significant amount of coupling.

例如，想象一下图 3-4中的引擎直接调用资源。虽然这种调用在技术上是可行的，但当你想切换资源或只是改变访问资源的方式时，突然间你所有的引擎都必须改变。客户端直接调用ResourceAccess服务怎么样？虽然这并不像调用资源本身那么糟糕，但所有的业务逻辑都必须迁移到客户端。任何对业务逻辑的更改都将迫使重新设计客户端。

For example, imagine in Figure 3-4 that the Engines directly call the Resources. While such a call is technically possible, when you wish to switch Resources or merely change the way you access a Resource, suddenly all your Engines must change. How about the Clients calling ResourceAccess services directly? While that is not as bad as calling the Resources themselves, all the business logic must migrate to the Clients. Any change to the business logic would then force reworking the Clients.

调用层也是不明智的。在图 3-4中，如果管理器调用客户端来更新 UI 中的某些控件，会怎么样？现在，随着 UI 的变化，管理器也必须对该变化做出响应。您已将客户端的波动性导入到管理器中。

Calling up a layer is also inadvisable. In Figure 3-4, what if a Manager called a Client to update some control in the UI? Now as the UI changes, the Manager must respond to that change, too. You have imported the volatility of the Clients to the Managers.

横向调用（层内调用）也会产生过多的耦合。想象一下图 3-4中的Manager A调用。在这种情况下，只是由执行的用例内部的活动。管理人员应该Manager BManager BManager A封装一组独立的用例。Manager B现在的用例是否独立于的用例？对执行活动的方式Manager A的任何更改都会破坏，这让人想起图 2-5中的问题。以这种方式横向调用几乎总是经理级别功能分解的结果。Manager BManager A

Calling sideways (intra-layer) also creates an inordinate amount of coupling. Imagine Manager A calling Manager B in Figure 3-4. In this case, Manager B is just an activity inside a use case executed by Manager A. Managers are supposed to encapsulate a set of independent use cases. Are the use cases of Manager B now independent of those of Manager A? Any change to Manager B’s way of doing the activity will break Manager A, calling to mind the issues of Figure 2-5. Calling sideways in this way is almost always the result of functional decomposition at the Managers level.

如何Engine A调用Engine B？是Engine B一个独立的易变活动？同样，功能分解可能是链接引擎Engine A调用需求的背后原因。

How about Engine A calling Engine B? Was Engine B a separate volatile activity from Engine A? Again, functional decomposition is likely behind the need to chain the Engines calls.

当使用开放式架构时，架构层本身几乎没有任何好处。一般来说，在软件工程中，用封装换取灵活性是一种糟糕的交易。

When using open architecture, there is hardly any benefit of having architectural layers in the first place. In general, in software engineering, trading encapsulation for flexibility is a bad trade.

封闭式架构

Closed Architecture

在封闭架构中，您努力通过禁止层与层之间向上调用和层内横向调用来最大限度地发挥层的优势。禁止层与层之间向下调用将最大限度地分离层与层之间的耦合，但会产生无用的设计。封闭架构在层之间打开了一个缝隙，允许一层中的组件调用相邻下层的组件。层中的组件为其上一层中的组件提供服务，但它们封装了下层发生的一切。封闭架构通过牺牲灵活性换取封装来促进分离。一般来说，这比反过来要好。

In a closed architecture, you strive to maximize the benefits of the layers by disallowing calling up between layers and sideways within layers. Disallowing calling down between layers would maximize the decoupling between the layers but produce a useless design. A closed architecture opens a chink in the layers, allowing components in one layer to call those in the adjacent lower layer. The components within a layer are of service to the components in the layer immediately above them, but they encapsulate whatever happens underneath. Closed architecture promotes decoupling by trading flexibility for encapsulation. In general, that is a better trade than the other way around.

半封闭/半开放式建筑

Semi-Closed/Semi-Open Architecture

很容易指出开放式架构的明显问题——允许向上、向下或横向调用。但是，这三种弊端是否同样严重？其中最糟糕的是向上调用：这不仅会产生跨层耦合，还会将较高层的波动性引入较低层。第二严重的弊端是横向调用，因为这种调用会耦合层内的组件。封闭式架构允许调用下一层，但如何向下调用多层呢？半封闭/半开放架构允许向下调用多个层。这又是用封装换取灵活性和性能，一般来说，这是一种应该避免的交易。

It is easy to point out the clear problems with open architectures—of allowing calling up, down, or sideways. However, are all three sins equally bad? The worst of them is calling up: That not only creates cross-layer coupling, but also imports the volatility of a higher layer to the lower layers. The second worst offender is calling sideways because such calls couple components inside the layer. The closed architecture allows calling one layer below, but what about calling multiple layers down? A semi-closed/semi-open architecture allows calling more than one layer down. This, again, is a trade of encapsulation for flexibility and performance and, in general, is a trade to avoid.

值得注意的是，在两种典型情况下，使用半封闭/半开放架构是合理的。第一种情况发生在你设计一些关键基础设施时，你必须从中榨干每一点性能。在这种情况下，过渡到降低多层可能会对性能产生不利影响。例如，考虑用于网络通信的七层开放系统互连 (OSI) 模型。5^当供应商在其 TCP 堆栈中实现此模型时，他们无法承受每次调用七层所带来的性能损失，因此他们明智地为堆栈选择了半封闭/半开放架构。第二种情况发生在几乎从不更改的代码库中。在这样的代码库中，封装的损失和额外的耦合无关紧要，因为您不必维护太多代码，甚至根本不需要维护。同样，网络堆栈实现是几乎从不更改的代码的一个很好的例子。

Notably, the use of semi-closed/semi-open architecture is justified in two classic cases. This first case occurs when you design some key piece of infrastructure, and you must squeeze every ounce of performance from it. In such a case, transitioning down multiple layers may adversely affect performance. For example, consider the Open Systems Interconnection (OSI) model of seven layers for network communication.⁵ When vendors implement this model in their TCP stack, they cannot afford the performance penalty incurred by seven layers for every call, and they sensibly choose a semi-closed/semi-open architecture for the stack. The second case occurs within a codebase that hardly ever changes. The loss in encapsulation and the additional coupling in such a codebase is immaterial because you will not have to maintain the code much, if at all. Again, a network stack implementation is a good example for code that hardly ever changes.

5. https://en.wikipedia.org/wiki/OSI_model

5. https://en.wikipedia.org/wiki/OSI_model

半封闭/半开放架构确实有其适用之处。然而，大多数系统的性能水平不足以证明这种设计是合理的，而且其代码库也并非一成不变。

Semi-closed/semi-open architectures do have their place. Nevertheless, most systems do not have the level of performance required to justify such designs, and their codebase is never that immutable.

放宽规则

Relaxing the Rules

对于实际的业务系统，最好的选择永远是封闭式架构。前面几节中对开放和半开放选项的讨论应该会阻止你做出任何其他选择。

For real-life business systems, the best choice is always a closed architecture. The discussion in the previous sections of the open and semi-open options should discourage you from any other choice.

虽然封闭架构系统是最解耦和最封装的，但它们也是最不灵活的。由于间接性和中介性，这种不灵活性可能导致拜占庭式的复杂性，而僵化的设计是不可取的。该方法放宽了封闭架构的规则，以降低复杂性和开销，而不会损害封装或解耦。

While closed architecture systems are the most decoupled and the most encapsulated, they are also the least flexible. This inflexibility could lead to Byzantine-like levels of complexity due to the indirections and intermediacy, and rigid design is inadvisable. The Method relaxes the rules of closed architecture to reduce complexity and overhead without compromising encapsulation or decoupling.

设计“禁忌”

Design “Don’ts”

有了服务和层的定义，还可以编制一份要避免的事情列表——设计“禁忌”。在阅读了前面几节之后，列表中的某些项目可能对您来说显而易见，但我经常看到它们，因此得出结论，它们毕竟并不明显。人们违背“禁忌”准则的主要原因是他们创建了功能分解，并设法说服自己它不是功能性的。

With the definitions in place for both the services and the layers, it is also possible to compile a list of things to avoid—the design “don’ts.” Some of the items on the list may appear obvious to you after the previous sections, yet I have seen them often enough to conclude they were not obvious after all. The main reason people go against a “don’t” guideline is that they have created a functional decomposition and have managed to convince themselves that it is not functional.

如果你做了以下列表中的某件事，你很可能后悔莫及。将任何违反这些规则的行为视为危险信号，并进一步调查以了解你遗漏了什么：

If you do one of the things on this list, you will likely live to regret it. Treat any violation of these rules as a red flag and investigate further to see what you are missing:

• 客户端不会在同一用例中调用多个管理器。这样做意味着管理器紧密耦合，不再代表单独的用例系列、单独的子系统或单独的片段。来自客户端的链式管理器调用表明功能分解，需要客户端将底层功能拼接在一起（参见图 2-1）。客户端可以调用多个管理器，但不能在同一用例中调用；例如，客户端可以调用以执行用例 1，然后调用以执行用例 2。Manager AManager B

• Clients do not call multiple Managers in the same use case. Doing so implies that the Managers are tightly coupled and no longer represent separate families of use cases, or separate subsystems, or separate slices. Chained Manager calls from the Client indicate functional decomposition, requiring the Client to stitch the underlying functionalities together (see Figure 2-1). Clients can call multiple Managers but not in the same use case; for example, a Client can call Manager A to perform use case 1 and then call Manager B to perform use case 2.

• 客户端不调用引擎。业务层的唯一入口点是管理器。管理器代表系统，而引擎实际上是内部层实现细节。如果客户端调用引擎，用例排序和相关波动性将被迫迁移到客户端，从而用业务逻辑污染它们。从客户端到引擎的调用是功能分解的标志。

• Clients do not call Engines. The only entry points to the business layer are the Managers. The Managers represent the system, and the Engines are really an internal layer implementation detail. If the Clients call the Engines, use case sequencing and associated volatility are forced to migrate to the Clients, polluting them with business logic. Calls from Clients to Engines are the hallmark of a functional decomposition.

• 在同一用例中，管理器不会将呼叫排队到多个管理器。如果有两个管理器接收排队呼叫，为什么不是第三个？为什么不是所有管理器？需要两个（或更多）管理器响应排队呼叫强烈表明需要更多管理器（也许是所有管理器）响应，因此您应该使用Pub/Sub 实用程序服务。

• Managers do not queue calls to more than one Manager in the same use case. If there are two Managers receiving a queued call, why not a third? Why not all of them? The need to have two (or more) Managers respond to a queued call is a strong indication that more Managers (and maybe all of them) would need to respond, so you should use a Pub/Sub Utility service instead.

• 引擎不接收排队调用。引擎是实用的，存在是为了为Manager执行不稳定的活动。它们本身没有独立的含义。根据定义，排队调用独立于系统中的任何其他内容执行。仅执行Engine的活动，与任何用例或其他活动脱节，没有任何商业意义。

• Engines do not receive queued calls. Engines are utilitarian and exist to execute a volatile activity for a Manager. They have no independent meaning on their own. A queued call, by definition, executes independently from anything else in the system. Performing just the activity of an Engine, disconnected from any use case or other activities, does not make any business sense.

• ResourceAccess服务不接收排队调用。与Engines指南非常相似，ResourceAccess服务用于为Manager或Engine提供服务，本身没有任何意义。独立于系统中的任何其他内容访问资源没有任何商业意义。

• ResourceAccess services do not receive queued calls. Very similar to the Engines guideline, ResourceAccess services exist to service a Manager or an Engine and have no meaning on their own. Accessing a Resource independently from anything else in the system does not make any business sense.

• 客户端不发布事件。事件代表客户端（或管理器）可能想要了解的系统状态变化。客户端无需通知自己（或其他客户端）。此外，通常需要了解系统内部情况才能检测发布事件的需要——客户端不应该知道这些知识。但是，通过功能分解，客户端就是系统，需要发布事件。

• Clients do not publish events. Events represent changes to the state of the system about which Clients (or Managers) may want to know. A Client has no need to notify itself (or other Clients). In addition, knowledge of the internals of the system is often required to detect the need to publish an event—knowledge that the Clients should not have. However, with a functional decomposition, the Client is the system and needs to publish the event.

• 引擎不发布事件。发布事件需要注意并响应系统中的变化，通常是由管理器执行的用例中的一个步骤。执行活动的引擎无法了解有关活动上下文或用例状态的太多信息。

• Engines do not publish events. Publishing an event requires noticing and responding to a change in the system and is typically a step in a use case executed by the Manager. An Engine performing an activity has no way of knowing much about the context of the activity or the state of the use case.

• ResourceAccess服务不发布事件。ResourceAccess服务无法知道资源状态对系统的重要性。任何此类知识或响应行为都应驻留在Managers中。

• ResourceAccess services do not publish events. ResourceAccess services have no way of knowing the significance of the state of the Resource to the system. Any such knowledge or responding behavior should reside in Managers.

• 资源不发布事件。资源发布事件的需求通常是紧密耦合的功能分解的结果。与ResourceAccess的情况类似，这种业务逻辑应驻留在Managers中。当Manager修改系统状态时，Manager也应发布相应的事件。

• Resources do not publish events. The need for the Resource to publish events is often the result of a tightly coupled functional decomposition. Similar to the case for ResourceAccess, business logic of this kind should reside in Managers. As a Manager modifies the state of the system, the Manager should also publish the appropriate events.

• Engines、ResourceAccess和Resources不订阅事件。处理事件几乎总是某些用例的开始，因此必须在Client或Manager中完成。Client可能会将事件通知给用户，而Manager可能会执行某些后端行为。

• Engines, ResourceAccess, and Resources do not subscribe to events. Processing an event is almost always the start of some use case, so it must be done in a Client or a Manager. The Client may inform a user about the event, and the Manager may execute some back-end behavior.

• 引擎从不相互调用。此类调用不仅违反了封闭架构原则，而且在基于波动性的分解中也没有意义。引擎应该已经封装了与该活动相关的所有内容。任何引擎到引擎的调用都表明功能分解。

• Engines never call each other. Not only do such calls violate the closed architecture principle, but they also do not make sense in a volatility-based decomposition. The Engine should have already encapsulated everything to do with that activity. Any Engine-to-Engine calls indicate functional decomposition.

• ResourceAccess服务从不相互调用。如果ResourceAccess服务封装了原子业务动词的易变性，则一个原子动词就不能需要另一个原子动词。这类似于引擎不应相互调用的规则。请注意，ResourceAccess和资源之间不需要1:1 映射（每个资源都有自己的ResourceAccess ）。通常，两个或多个资源在逻辑上必须连接在一起才能实现某些原子业务动词。单个ResourceAccess服务应该执行连接，而不是ResourceAccess服务之间的调用。

• ResourceAccess services never call each other. If ResourceAccess services encapsulate the volatility of an atomic business verb, one atomic verb cannot require another. This is similar to the rule that Engines should not call each other. Note that a 1:1 mapping between ResourceAccess and Resources (every Resource has its own ResourceAccess) is not required. Often two or more Resources logically must be joined together to implement some atomic business verbs. A single ResourceAccess service should perform the join rather than inter-ResourceAccess services calls.

力求对称

Strive for Symmetry

另一个通用的设计规则是所有好的架构都是对称的。想想你自己的身体。你没有第三只手伸出来在你的右侧，因为进化的压力是全方位的，强制对称。进化软件系统也面临压力，迫使系统对不断变化的环境做出反应，否则就会灭绝。然而，对对称性的追求只是在架构层面，而不是在详细设计层面。当然，你的内脏器官不是对称的，因为这种对称性并没有给你的祖先带来进化优势（即，当你暴露其内部结构时，系统就会消亡）。

Another universal design rule is that all good architectures are symmetric. Consider your own body. You do not have a third hand sticking up on your right side because evolutionary pressures were omnidirectional, enforcing symmetry. Evolutionary pressures apply to software systems as well, forcing the systems to respond to the changing environment or become extinct. The quest for symmetry, however, is only at the architecture level, not in detailed design. Certainly, your internal organs are not symmetric because such symmetry offered no evolutionary advantage to your ancestors (i.e., the system dies when you expose its internals).

软件系统中的对称性表现为跨用例的重复调用模式。您应该预料到对称性，而它的缺失则值得关注。例如，假设一个Manager实现了四个用例，其中三个使用Pub/Sub服务发布事件，而第四个没有发布。这种对称性的破坏是一种设计异味。为什么第四个案例不同？你遗漏了什么或者做得太过分了？那个Manager是真正的Manager，还是一个没有波动性的功能分解组件？对称性还会因某种东西的存在而被破坏，而不仅仅是因为它的缺失。例如，如果一个Manager实现了四个用例，其中只有一个用例最终会排队调用另一个Manager，那么这种不对称也是一种异味。对称性对于好的设计如此重要，以至于您通常应该在各个Manager中看到相同的调用模式。

The symmetry in software systems manifests in repeated call patterns across use cases. You should expect symmetry, and its absence is a cause for concern. For example, suppose a Manager implements four use cases, three of which publish an event with the Pub/Sub service and the fourth of which does not. That break of symmetry is a design smell. Why is the fourth case different? What are you missing or overdoing? Is that Manager a real Manager, or is it a functionally decomposed component without volatility? Symmetry can also be broken by the presence of something, not just by its absence. For example, if a Manager implements four use cases, of which only one ends up with a queued call to another Manager, that asymmetry is also a smell. Symmetry is so fundamental for good design that you should generally see the same call patterns across Managers.

厌恶改变

Resenting Change

尽管需求变更是一件美妙的事情，但业内许多人的整个职业生涯都在憎恨这种变更。原因很简单：大多数开发人员和架构师都是根据需求来设计系统的。事实上，他们不遗余力地将需求转录到架构的组件中。他们努力使需求和系统设计之间的亲和力最大化。然而，当需求发生变化时，他们的设计也必须改变。在任何系统中，设计的改变都是非常痛苦的，往往是破坏性的，而且总是代价高昂。因为没有人喜欢痛苦（即使是自己造成的，就像在这种情况下），人们已经学会了憎恨需求的变更，实际上是憎恨给他们提供便利的人。

As wonderful as changes to requirements are, many in the industry have spent their entire career resenting such changes. The reason is simple: Most developers and architects design their system against the requirements. In fact, they go to great lengths to transcribe the requirements to components of the architecture. They strive to maximize the affinity between the requirements and the system design. However, when the requirements change, their design also must change. In any system, a change to the design is very painful, often destructive, and always expensive. Since nobody likes pain (even when it is self-inflicted, as in this case), people have learned to resent changes to requirements, literally resenting the hand that feeds them.

设计首要指令

Design Prime Directive

解决这种对变革不满的不和谐之感的方法非常简单，几乎每个人在整个职业生涯中都未能找到它：

The solution for this dissonance of resenting the changes is so simple that it has eluded almost everyone for their entire career:

永远不要违背要求进行设计。

Never design against the requirements.

这一简单的指令与大多数人所学和实践的内容相悖，尽管它本应是显而易见的。任何违背需求进行设计的尝试都必然会带来痛苦。既然痛苦是糟糕的，那么就不应该为做如此不明智的事情找借口。人们甚至可能完全意识到他们的设计过程无法奏效，而且从未奏效过，但由于缺乏替代方案，他们只能求助于他们所知道的唯一选择——违背需求进行设计。

This simple directive goes contrary to what most have been taught and have practiced, even though it should have been plainly evident for all to see. Any attempt at designing against the requirements will always guarantee pain. Since pain is bad, there should be no excuse for doing something that is so ill advised. People may even be fully aware that their design process cannot work and has never worked, but lacking alternatives they resort to the one option they know—to design against the requirements.

核心用例

Core Use Cases

在任何给定系统中，并不是所有用例都是独特且唯一的。大多数用例都是其他用户用例的变体。主要的必需行为有无数种排列组合 — 例如，正常情况、不完整情况、特定区域的特定客户情况、错误情况等等。用例只有两种类型：核心用例和所有其他用例。核心用例代表系统业务的本质。如第 2 章所述，业务性质几乎不会改变，核心用例也是如此。当然，常规的非核心用例会在业务的客户之间发生很大变化。虽然您的客户可以并且可能会对常规用例有自己的定制和解释，但所有客户都共享核心用例。

In any given system, not all use cases are distinct and unique. Most of the use cases are variations of other user cases. The main required behavior has numerous permutations—for example, the normal case, the incomplete case, the case for a specific customer in a particular locale, the error case, and so on. There are only two types of use cases: core use cases and all other use cases. The core use cases represent the essence of the business of the system. As discussed in Chapter 2, the nature of the business hardly ever changes, and the same goes for the core use cases. The regular, non-core use cases will, of course, change at great rate across and between customers of the business. While your customers can and likely will have their own customization and interpretation of the regular use cases, all customers share the core use cases.

虽然系统可能有数百个用例，但值得庆幸的是，系统只有少数几个核心用例。在 IDesign 的实践中，我们经常看到系统的核心用例少得惊人。大多数系统只有两三个核心用例，而且数量很少超过六个。回想一下办公室里的系统或您最近参与的项目，在脑海中计算一下系统需要处理的真正不同用例的数量。您会发现这个数字很少，非常少。或者，拿出系统的单页营销手册，数一数项目符号的数量。您可能不会超过三个项目符号。

While the system may have hundreds of use cases, the saving grace is that the system will have only a handful of core use cases. In our practice at IDesign, we commonly see systems with surprisingly few core use cases. Most systems have as few as two or three core use cases, and the number seldom exceeds six. Reflect on your system at the office or on a recent project with which you were involved and count in your head the number of truly distinct use cases the system is required to handle. You will find that this number is small, very small. Alternatively, bring up a single-page marketing brochure for the system and count the number of bullets. You will likely have no more than three bullets.

建筑师的使命

The Architect’s Mission

作为架构师，您的任务是确定可以组合在一起以满足所有核心用例的最小组件集。由于所有其他用例都只是核心用例的变体，因此常规用例仅表示组件之间的不同交互，而不是不同的分解。现在，当需求发生变化时，您的设计不会发生变化。

Your mission as an architect is to identify the smallest set of components that you can put together to satisfy all the core use cases. Since all the other use cases are merely variations of the core use cases, the regular use cases simply represent a different interaction between the components, not a different decomposition. Now when the requirements change, your design does not.

我把这种方法称为可组合设计。可组合设计并不旨在满足任何特定的用例。

I call this approach composable design. A composable design does not aim to satisfy any use case in particular.

您不会特别针对任何用例，这不仅是因为您收到的用例不完整、有缺陷且漏洞百出、自相矛盾，还因为它们会发生变化。即使现有用例不会改变，随着时间的推移，您也会添加新用例并删除其他用例。

You do not target any use case in particular not just because the use cases you were given were incomplete, faulty, and full of holes and contradictions, but because they will change. Even if the existing use case will not change, over time you will have new use cases added and others removed.

一个简单的例子就是人体设计。20多万年前，智人出现在非洲平原，当时的职位要求中还没有软件架构师。你怎么可能用狩猎采集者的身体来满足当今软件架构师的要求呢？答案是，虽然你使用与史前人类相同的组件，但你以不同的方式整合它们。单一的核心用例并没有随着时间的推移而改变：生存。

A simple example is the design of the human body. Homo sapiens appeared on the plains of Africa more than 200,000 years ago, when the requirements at the time did not include being a software architect. How can you possibly fulfill the requirements for a software architect today while using the body of a hunter-gatherer? The answer is that while you are using the same components as a prehistoric man, you are integrating them in different ways. The single core use case has not changed with time: survive.

架构验证

因为任何系统的目标都是满足需求，可组合设计可以实现另一件事：设计验证。一旦您可以针对每个核心用例在服务之间生成交互，您就生成了一个有效的设计。无需了解未知事物或预测未来。您的设计现在可以处理任何用例，因为所有用例都只表现为相同构建块之间的不同交互。不要再向往某个神秘的项目了，总有一天有人会给您提供所有完整且正确记录的需求。没有必要在前期浪费大量时间试图详细确定需求。即使需求严重受损，您也可以轻松设计有效的系统。

Since the goal of any system is to satisfy the requirements, composable design enables something else: design validation. Once you can produce an interaction between your services for each core use case, you have produced a valid design. There is no need to know the unknown or to predict the future. Your design can now handle any use case, because all use cases manifest themselves only as different interactions between the same building blocks. Stop yearning for some mythical project where one day someone will give you all the requirements complete and properly documented. There is no point in wasting inordinate amount of time up front trying to nail down the requirements in minute detail. You can easily design valid systems even with grossly impaired requirements.

验证设计的过程可以简单到只需生成简单的图表来演示支持用例的架构组件之间的交互。图 4-1按照方法的说法是调用链图。

The act of validating the design can be as straightforward as producing simple diagrams demonstrating the interactions between the components of the architecture that support the use cases. Figure 4-1 is, in The Method’s parlance, a call chain diagram.

调用链展示了满足特定用例所需的组件之间的交互。您可以将调用链直接叠加到分层架构图上。图中的组件通过箭头连接，指示组件之间调用的方向和类型 - 实心黑色箭头表示同步（请求/响应）调用，虚线灰色箭头表示排队调用。调用链图是依赖关系图的特化，因此在项目设计期间非常有用（如本书后半部分所述）。

A call chain demonstrates the interaction between components required to satisfy a particular use case. You can literally superimpose the call chain onto the layered architecture diagram. The components in the diagram are connected by arrows indicating the direction and type of the call between components—a solid black arrow for synchronous (request/response) calls, and a dashed gray arrow for a queued call. Call chain diagrams are specializations of a dependency graph and as such are quite useful during project design (as discussed in the second half of this book).

调用链图是一种简单快捷的检查用例和演示设计如何支持用例的方法。调用链图的缺点是它们没有调用顺序的概念，无法捕获调用的持续时间，并且当多方对同一类型的组件进行多次调用时，它们会变得混乱。在许多情况下，组件之间的交互可能很简单，因此您不需要显示顺序、持续时间或多次调用。对于这些情况，您可以决定调用链图足以满足验证目的。此外，非技术受众通常更容易理解调用链。

Call chain diagrams are a simple and quick way of examining a use case and demonstrating how the design supports it. The downside of call chain diagrams is that they have no notion of call order, they have no way of capturing the duration of the calls, and they get confusing when multiple parties make multiple calls to the same type of components. In many cases, the interaction between the components may be simple, so you do not need to show order, duration, or multiple calls. For these cases, you may decide that a call chain diagram is good enough for the validation purpose. Also, call chains are often easier for nontechnical audiences to understand.

方法论中的序列图类似于 UML 序列图。1^但是，它包含符号差异，以确保图表类型之间具有共同的含义。生命线根据架构层着色，箭头样式与调用链图中的箭头样式相同。图 4-2是与图 4-1等效的序列图。

A sequence diagram in The Method’s parlance is similar to a UML sequence diagram.¹ However, it includes notational differences to assure common meanings between diagram types. Lifelines are colored according to the architectural layers, and the arrow styles are the same as in call chain diagrams. Figure 4-2 is a sequence diagram equivalent to Figure 4-1.

1. https://en.wikipedia.org/wiki/Sequence_diagram

1. https://en.wikipedia.org/wiki/Sequence_diagram

在序列图中，用例中的每个参与组件都有一个垂直条，表示其生命线。垂直条对应于组件执行的某些工作或活动。时间从图的顶部流向底部，条的长度表示组件使用的相对持续时间。单个组件可能多次参与同一个用例，并且您甚至可以为同一组件的不同实例设置不同的生命线。水平箭头（实线黑色表示同步，虚线灰色表示排队）表示组件之间的调用。

In a sequence diagram, each participating component in the use case has a vertical bar representing its lifeline. The vertical bars correspond to some work or activity that the component performs. Time flows from top to bottom of the diagram, and the length of the bars indicates the relative duration of the component’s use. A single component may participate multiple times in the same use case, and you can even have different lifelines for different instances of the same component. The horizontal arrows (solid black for synchronous and dashed gray for queued) indicate calls between components.

由于序列图提供了额外的细节层次，因此制作序列图需要更长的时间，但它们通常是演示复杂用例的合适工具，尤其是对于技术受众而言。此外，序列图在后续详细设计中非常有用，有助于定义接口、方法甚至参数。如果您要为详细设计制作它们，那么不妨先为设计验证制作它们，尽管细节较少（例如，暂时省略操作和消息）。

Sequence diagrams take longer to produce due to the additional level of details they offer, but they are often the right tool to demonstrate a complex use case, especially for technical audience. In addition, sequence diagrams are extremely useful in subsequent detailed design for helping to define interfaces, methods, and even parameters. If you are going to produce them for the detailed design, you might as well produce them first for design validation, albeit with fewer details (e.g., omit operations and messages for now).

遏制变革

Containing the Change

应对变化的诀窍不是与之对抗、推迟或完全逃避。诀窍在于控制其影响。考虑使用基于波动性的分解和第 3 章的结构指南设计的系统。对需求的更改实际上是对系统所需行为的更改 — 具体来说，是对用例的更改。在方法中，某个管理器实现执行用例的工作流。管理器可能会受到更改的严重影响。也许您甚至需要丢弃该管理器的整个实现并在其位置创建一个新的。但是，管理器集成的底层组件不会受到对所需行为的更改的影响。

The trick to addressing change is not to fight it, postpone it, or punt it altogether. The trick is containing its effects. Consider a system designed using volatility-based decomposition and the structure guidelines of Chapter 3. A change to a requirement is actually a change to the required behavior of the system—specifically, a change to a use case. In The Method, some Manager implements the workflow executing the use case. The Manager may be gravely affected by a change. Perhaps you even need to discard the whole implementation of that Manager and create a new one in its place. However, the underlying components that the Manager integrates are not affected by the change to the required behavior.

回想一下第 3 章，管理器应该是几乎可消耗的。这使您能够吸收变更的成本，以控制变更。此外，任何系统中的大部分工作通常都投入到管理器使用的服务中：

Recall from Chapter 3 that the Manager should be almost expendable. This enables you to absorb the cost of the change, to contain it. Furthermore, the bulk of the effort in any system typically goes into the services that the Manager uses:

• 实施引擎的成本很高。每个引擎都代表着对系统工作流至关重要的业务活动，并封装了相关的波动性和复杂性。

• Implementing Engines is expensive. Each Engine represents business activities vital to the system’s workflows and encapsulates the associated volatility and complexity.

• 实现ResourceAccess并非易事，这不仅仅是因为编写ResourceAccess代码的成本。识别原子业务动词、将它们转换为某些Resource的访问方法并将它们公开为Resource中立的接口也需要付出巨大努力。

• Implementing a ResourceAccess is nontrivial, and not just because of the cost of writing the ResourceAccess code. Identifying the atomic business verbs, translating them into the access methodologies for some Resource, and exposing them as a Resource-neutral interface also takes a significant effort.

• 设计和实现可扩展、可靠、高性能且可重复使用的资源非常耗时耗力。这些任务可能包括设计数据契约、架构、缓存访问策略、分区、复制、连接管理、超时、锁定管理、索引、规范化、消息格式、事务、传递失败、毒药消息等等。

• Designing and implementing Resources that are scalable, reliable, highly performant, and very reusable is time- and effort-consuming. These tasks may include designing data contracts, schemas, cache access policies, partitioning, replication, connection management, timeouts, lock management, indexing, normalization, message formats, transactions, delivery failures, poison messages, and much more.

• 实现实用程序始终需要顶级技能，而且结果必须值得信赖。实用程序是系统的支柱。世界一流的安全性、诊断、日志记录、消息处理、仪表和托管并非偶然发生。

• Implementing Utilities always requires top skills, and the result must be trustworthy. Utilities are the backbone of your system. World-class security, diagnostics, logging, message processing, instrumentation, and hosting do not happen accidentally.

• 为客户设计出色的用户体验或方便且可重复使用的 API需要耗费大量时间和人力。客户还必须与管理器进行交互和集成。

• Designing a superior user experience or a convenient and reusable API for Clients is time and labor intensive. The Clients also have to interface and integrate with the Managers.

当Manager发生变更时，您可以挽救并重用在Clients、Engines、ResourceAccess、Resources和Utilities上所做的所有工作。通过在 Manager 中重新集成这些服务，您已控制了变更，并可以快速高效地响应变更。这难道不是敏捷的本质吗？

When a change happens to the Manager, you get to salvage and reuse all the effort that went into the Clients, the Engines, the ResourceAccess, the Resources, and the Utilities. By reintegrating these services in the Manager, you have contained the change and can quickly and efficiently respond to changes. Is that not the essence of agility?

遗留系统

Legacy System

部署在欧洲呼叫中心的旧系统拥有全职用户，他们依赖于连接到数据库的两层桌面应用程序。商人和承包商都会打电话进来，代表输入详细信息，甚至实时进行匹配。一些用于管理会员的基本 Web 门户绕过旧系统，直接与数据库一起工作。各种子系统是孤立的，效率非常低，几乎每一步都需要大量的人工干预。用户需要使用多达五个不同的应用程序来完成他们的任务。这些应用程序是独立的，集成是手动完成的。客户端应用程序充满了业务逻辑，UI 和业务逻辑之间缺乏分离，阻碍了应用程序更新到现代用户体验。

The legacy system, which is deployed in European call centers, has full-time users who rely on a two-tier desktop application connected to a database. Both tradesmen and contractors call in, with the reps entering the details and even performing the matching in real time. Some rudimentary web portals for managing membership bypass the legacy system and work with the database directly. The various subsystems are isolated and very inefficient, requiring a lot of human intervention at almost every step. Users are required to employ as many as five different applications to accomplish their tasks. These applications are independent, and the integration is done by hand. The client applications are chock-full of business logic, and the lack of separation between UI and business logic prevents updating the applications to modern user experience.

每个子系统甚至都有自己的存储库，用户必须协调它们才能理解所有内容。这个过程很容易出错，并且会给新用户带来昂贵的培训和入门时间。

Each subsystem even has its own repository, and the users have to reconcile them to make sense of it all. This process is error prone and imposes expensive training and onboarding time for new users.

遗留系统存在漏洞，其随意的安全方法使其面临许多可能的攻击媒介。遗留系统在设计时从未考虑过安全性。事实上，它根本没有设计，而是自然发展起来的。

The legacy system is vulnerable, and its haphazard approach to security exposes it to many possible attack vectors. The legacy system was never designed with security in mind. For that matter, it was never designed at all, but rather grew organically.

旧版本根本无法容纳以下几个新特性和所需的能力：

The legacy simply cannot accommodate several new features and desirable capabilities:

• 移动设备支持

• Mobile device support

• 工作流程自动化程度更高

• Higher degree of automation of the workflow

• 与其他系统的一些连接

• Some connectivity to other systems

• 迁移到云

• Migration to the cloud

• 欺诈检测

• Fraud detection

• 工作质量调查，包括将工匠的安全记录纳入工资和技能水平

• Quality of work surveys, including incorporating the tradesman’s safety record in the rate and skill level

• 进入新市场（例如在船厂部署）

• Entering new markets (such as deployment at marine yards)

企业和用户都对旧系统无法与时俱进感到沮丧，而且人们总是在不断地寻求增值功能。其中一项功能，即继续教育，原来是必备的，所以它被拼凑在旧系统之上。旧系统将工匠分配到认证课程和政府要求的测试，并跟踪工匠的进度。虽然外部教育中心提供培训并注册认证，但用户必须手动将它们与旧系统连接起来。虽然与核心系统方面无关，但工匠和企业都非常喜欢这个功能，因为认证功能有助于防止工匠转向竞争对手。

Both the business and users are frustrated with the legacy system’s inability to keep up with the times, and there is a never-ending stream of desired value-added features. One such feature, continuing education, turned out to be a must-have, so it was cobbled on top of the legacy system. The legacy system assigns tradesmen to certification classes and government-required tests and tracks the tradesmen’s progress. Although external education centers provide training and register the certifications, the users have to manually connect them with the legacy system. While unrelated to the core system aspects, tradesmen are really keen on this feature, as is the business, because the certification feature helps prevent tradesmen from moving to the competitors.

旧系统难以遵守各个地区的新法规。处理任何变化都非常困难，而且该系统高度针对其当前的业务环境。由于该公司无法负担为每个地区支持不同版本的系统，因此它产生了将系统简化为各个地区最低标准的动机。这进一步增加了用户的手动工作流程负担，从而降低了效率，增加了培训时间和成本，并导致业务机会的损失。

The legacy system is having trouble complying with new legislation across locales. Dealing with any change is very difficult, and the system is highly specific for its current business context. Since the company cannot afford to support a unique version of the system per locale, it created an incentive to dumb down the system to the lowest common denominator across locales. This further increases the burden on the users in terms of their manual workflows, which decreases efficiency, increases training time and costs, and causes loss of business opportunities.

总体而言，该系统在所有地点拥有约 220 名代表。可扩展性和吞吐量都不是问题。但是，响应能力是一个问题，尽管这可能只是遗留系统的一个副作用。

Overall, the system has some 220 reps across all locations. Neither scalability nor throughput poses a problem. However, responsiveness is an issue, although this may just be a side effect of the legacy system.

新系统

New System

鉴于设计不良的遗留系统存在的问题，公司管理层希望设计一个正确的新系统。新系统应尽可能地实现工作自动化。理想情况下，公司希望拥有一个小型呼叫中心，用作自动化流程的备份。该呼叫中心将在所有地区使用单一系统。虽然该系统部署在欧洲，但也有要求在英国¹甚至加拿大（即欧盟以外）部署该系统。投资新系统的另一个驱动因素是竞争对手的系统更加灵活、高效，用户体验也更出色。

Given the issues of the poorly designed legacy, the company’s management is interested in designing a new system correctly. The new system should automate the work as much as possible. Ideally, the company would like to have a single, small call center that is used as a backup for an automated process. This call center would use a single system across all locales. While the system is deployed in Europe, there are requests to deploy the system in the United Kingdom¹ and even Canada (i.e., outside the European Union). Another driver for investing in the new system is that the competitors have much more flexible, efficient systems, with superior user experience.

1.虽然这一设计工作是在英国脱欧（英国脱离欧盟）之前进行的，但英国脱欧是一个典型例子，它是一种当时未曾预料到的大规模变革，但新系统却无缝地适应了它。

1. While this design effort took place prior to Brexit (the departure of the United Kingdom from the EU), Brexit is a classic example of a massive change that was unanticipated at the time, yet the new system accommodated it seamlessly.

虽然承包商可以使用多种来源的工匠（包括竞争产品）为项目配备人员，但与竞争产品的集成以及项目优化通常超出了该系统的范围：该公司不从事优化或集成业务。将市场扩大到包括 IT 或护理等其他行业也超出了范围。增加这些市场将重新定义业务的性质，而该公司的强项是将工匠与建筑项目相匹配，而不是一般的人员配备。

While contractors could staff a project using multiple sources of tradesmen, including competing products, integration with competing products and project optimizations in general are beyond the scope of the system: The company is not in the business of optimization or integration. Expanding the marketplace to include other trades such as IT or nursing is also out of scope. Adding these markets would redefine the nature of the business, and the company’s forte is matching tradesmen to construction projects, not general staffing.

公司

The Company

该公司将自己视为贸易经纪人，而不是软件组织。软件不是其业务。过去，该公司没有认识到开发优秀软件真正需要什么。该公司没有投入足够的精力进行流程或开发实践。该公司过去建立替代系统的尝试都失败了。该公司确实拥有充足的财务资源——遗留应用程序非常有利可图。过去的惨痛教训让管理层决定翻开新的一页，采用合理的软件开发方法。

The company views itself as a tradesmen broker, not as a software organization. Software is not its business. In the past the company did not acknowledge what it would really take to develop great software. The company did not devote adequate effort to process or development practices. The company’s attempts to build a replacement system in the past all failed. What the company does have is plenty of financial resources—the legacy application is very profitable. The bitter lessons of the past have convinced management to turn a new page and adopt a sound approach for software development.

使用案例

Use Cases

旧系统和新系统均没有现成的需求文档。客户能够提供图 5-1至5-8，描述一些用例。这些用例可能是也可能不是核心用例；它们只是系统所需的行为。在很大程度上，这些用例反映了遗留系统应该做的事情。由于设计团队正在寻找核心用例，他们忽略了低级用例，例如输入财务详细信息、向承包商收取费用以及向商人支付款项。一些用例，例如继续教育，甚至没有指定。此外，显然还有空间可以添加其他用例来补充公司提供的用例。

There were no existing requirements documents for either the old system or the new system. The customer was able to provide Figures 5-1 to 5-8, depicting some use cases. These may or may not be core use cases; they are simply the required behaviors of the system. To a large extent, the use cases reflected what the legacy system was supposedly doing. Since the design team was looking for core use cases, they ignored low-level use cases such as entering financial details, collecting fees from contractors, and distributing payments to tradesmen. Some use cases, such as continuing education, were not even specified. Moreover, there was clearly room for additional use cases complementing the use cases provided by the company.

简化用例

客户很少会以有用的格式提出需求，更不用说以有利于良好设计的方式提出需求。您必须始终转换、澄清和整合原始数据。在设计过程的早期，您甚至可能识别出交互区域，这将使以后将这些区域映射到子系统或层变得更加自然。例如，对于 TradeMe，所有用例中至少有三种类型的角色：用户、市场和会员。用户可以是后台数据输入代表或系统管理员。也许只有管理员才能解雇商人，但图 5-5中没有提供该信息。

Customers rarely ever present the requirements in a useful format, let alone in a way that is conducive to good design. You must always transform, clarify, and consolidate the raw data. Early in the design process you may even recognize areas of interaction that will later make mapping the areas to subsystems or layers much more natural. For example, with TradeMe, there were at least three types of roles across all the use cases: the users, the market, and the members. The users can be back-office data entry reps or system administrators. Perhaps only an administrator can terminate a tradesman, but that information was absent from Figure 5-5.

在活动图中使用“泳道”来显示角色、组织和其他负责实体之间的控制流很有用。例如，图 5-9提供了另一种表达图 5-5中的 Terminate Tradesman 用例的方法。

It is useful to show the flow of control between roles, organizations, and other responsible entities, using “swim lanes” in your activity diagrams. For example, Figure 5-9 provides an alternative way of expressing the Terminate Tradesman use case from Figure 5-5.

通过将活动图细分为交互区域，可以转换原始用例。这还有助于通过根据需要添加决策框或同步栏来明确系统所需的行为。您将在本章后面看到如何使用泳道技术来启动和验证设计。

You transform the raw use case by subdividing the activity diagram into areas of interactions. This also helps clarify the required behavior of the system by adding decision boxes or synchronization bars as required. You will see how to use the swim lanes technique later on in this chapter to both initiate and validate the design.

巨石

The Monolith

一个简单的反设计示例是上帝服务——一个丑陋的垃圾场，将所有需求中的功能都放在一个地方实现。虽然这种设计非常常见，甚至有一个名字（Monolith），但现在大多数人已经从惨痛的经历中吸取了教训，不要这样设计。

One simple anti-design example is a god service—an ugly dumping ground of all the functionalities in the requirements, all implemented in one place. While this design is so common it even has a name (the Monolith), by now most people have learned the hard way not to design this way.

粒状构建块

Granular Building Blocks

图 5-10显示了反设计的另一种表现形式：大量的构建块。用例中的每个活动实际上在架构中都有相应的组件。数据库访问或数据库本身均未封装。

Figure 5-10 shows another take on the anti-design: a massive set of building blocks. Literally every activity in the use cases has a corresponding component in the architecture. There is no encapsulation of either the database access or the database itself.

有了这么多的细粒度块，客户端就负责实现用例的业务逻辑，如图 5-11所示。将客户端的代码与业务逻辑合并，导致客户端臃肿，整个系统迁移到客户端上，如图2-1所示。

With so many fine-grained blocks, the Clients become responsible for implementing the business logic of the use cases, as shown in Figure 5-11. Contaminating the Client’s code with business logic results in a bloated Client in which the entire system migrates to the Client, as shown in Figure 2-1.

或者，您可以让服务相互调用，如图5-12所示。但是，以这种方式将功能强大的服务链接在一起会导致它们之间产生耦合，如图 2-5所示。还请注意图 5-12中向上和横向调用的开放架构问题。

Alternatively, you can have the services call each other, as shown in Figure 5-12. However, chaining the highly functional services together in this way creates coupling between them, as depicted in Figure 2-5. Note also in Figure 5-12 the open architecture issues of calling up and sideways.

域分解

Domain Decomposition

另一个经典的反设计是沿域线分解，如图5-13所示。这里系统沿Tradesman、Contractor和的域线分解Project。

Another classic anti-design is to decompose along the domain lines, as shown in Figure 5-13. Here the system is decomposed along the domain lines of Tradesman, Contractor, and Project.

即使是TradeMe 这样相对简单的系统，域名分解的可能性也几乎是无限的，例如，，，，，，，，，，，，，，，，，等等。谁能说Accounts比更适合Administration做域名？应该使用哪些标准来做出判断？AnalyticsApprovalAssignmentCertificatesContractsCurrencyDisputesFinanceFulfillmentLegislationPayrollReportsRequisitionStaffingSubscriptionProjectAccounts

Even with a relatively simple system such as TradeMe, there are nearly limitless additional possibilities for domain decomposition, such as Accounts, Administration, Analytics, Approval, Assignment, Certificates, Contracts, Currency, Disputes, Finance, Fulfillment, Legislation, Payroll, Reports, Requisition, Staffing, Subscription, and so on. Who is to say that Project is a better candidate for a domain than Accounts? And which criteria should be used to make that judgment?

除了第 2 章中讨论的诸多缺点之外，域分解还使得通过展示用例支持来验证设计几乎不可能。例如，对工匠的请求将同时出现在Project和Tradesman域服务上。由于跨域功能重复，因此很难确定谁在何时做什么。

Besides having the many drawbacks discussed in Chapter 2, domain decomposition makes it nearly impossible to validate the design by demonstrating support of the use cases. For example, a request for a tradesman will appear on both the Project and Tradesman domain services. Due to the duplication of functionalities across domain lines, it is ambiguous who is doing what and when.

愿景

The Vision

在任何环境中，很少有人会对系统应该做什么有相同的看法。有些人可能根本没有看法。其他人的看法可能与其他人不同，或者只服务于他们狭隘的利益。有些人可能会误解业务目标。TradeMe 背后的公司因未能跟上不断变化的市场而陷入了无数额外的问题。这些问题反映在现有系统、公司结构和软件开发设置方式中。新系统必须正面解决所有问题，而不是零敲碎打，因为只解决其中一些问题不足以取得成功。

Seldom will everyone in any environment share the same vision as to what the system should do. Some may have no vision at all. Others may have a different vision than the rest or a vision that serves only their narrow interests. Some may misinterpret the business goals. The company behind TradeMe was stymied by a myriad of additional issues resulting from its failure to keep up with the changing market. These issues were reflected in the existing systems, in the company’s structure, and in the way software development was set up. The new system had to tackle all the issues head-on rather than in a piecemeal fashion, because solving just some of them was insufficient for success.

首要任务是让所有利益相关者就共同愿景达成一致。愿景必须推动一切，从架构到承诺。你之后所做的一切都必须服务于这一愿景并以此为依据。当然，这是双向的——这就是为什么从愿景开始是个好主意。如果某件事不符合愿景，那么它通常与政治和其他次要或第三要务有关。这为你提供了一种极好的方式来拒绝不支持商定愿景的无关要求。在 TradeMe 的案例中，设计团队将愿景提炼为一句话：

The first order of business is to get all stakeholders to agree on a common vision. The vision must drive everything, from architecture to commitments. Everything that you do later has to serve that vision and be justified by it. Of course, this cuts both ways—which is why it is a good idea to start with the vision. If something does not serve the vision, then it often has to do with politics and other secondary or tertiary concerns. This provides you with an excellent way of repelling irrelevant demands that do not support the agreed-upon vision. In the case of TradeMe, the design team distilled the vision to a single sentence:

一个用于构建应用程序以支持 TradeMe 市场的平台。

A platform for building applications to support the TradeMe marketplace.

好的愿景既简洁又明确。你应该像读法律声明一样去阅读它。请注意，TradeMe 的愿景是构建一个平台来构建应用程序。这种平台思维解决了企业渴望的多样性和可扩展性，并且可能适用于您设计的系统。

A good vision is both terse and explicit. You should read it like a legal statement. Note that the vision for TradeMe was to build a platform on which to build the applications. This kind of platform mindset addressed the diversity and extensibility the business craved and may be applicable in systems you design.

业务目标

The Business Objectives

在就愿景达成一致后（并且只有在那时），您可以将愿景逐项列出具体目标。您应该拒绝所有不符合愿景的目标；您应该包括所有对支持愿景至关重要的目标。这两种类型通常很容易挑选出来。列出目标时，您应该采用业务视角。您不能让工程或营销人员主导对话，也不能包括技术目标或具体要求。设计团队从 TradeMe 系统概述中提取了以下目标：

After agreeing on the vision (and only then), you can itemize the vision to specific objectives. You should reject all objectives that do not serve the vision; you should include all objectives that are essential to support the vision. These two types are usually easy to pick out. When you list objectives, you should adopt a business perspective. You must not allow the engineering or marketing people to own the conversation, or to include technology objectives or specific requirements. The design team extracted the following objectives from the TradeMe system overview:

1. 统一存储库和应用程序。旧系统存在太多低效问题，需要大量人工干预才能使系统保持最新状态并正常运行。

2. Unify the repositories and applications. The legacy system had entirely too many inefficiencies, requiring a lot of human intervention to keep the system up to date and running.

3. 快速满足新需求。传统功能的交付时间非常糟糕。新平台必须允许非常快速、频繁的定制，通常只针对特定技能、一周中的某个时间、项目类型以及这些的任意组合进行定制。理想情况下，从编码到部署，这种快速交付的大部分工作都应该实现自动化。

4. Quick turnaround for new requirements. The legacy turnaround time for features was abysmal. The new platform had to allow very fast, frequent customization, often tailored just for a specific skill, time of the week, project type, and any combination of these. Ideally, much of this quick turnaround should be automated, from coding to deployment.

5. 支持跨国家和跨市场的高度定制。由于法规、立法、文化和语言的差异，本地化是一个令人难以置信的痛点。

6. Support a high degree of customization across countries and markets. Localization was an incredible pain point because of differences in regulations, legislations, cultures, and languages.

7. 支持全面的业务可视性和责任制。传统系统不具备欺诈检测、审计跟踪和监控功能。

8. Supports full business visibility and accountability. Fraud detection, audit trails, and monitoring were nonexistent in the legacy system.

9. 前瞻性地看待技术和法规。系统必须预测变化，而不是永远处于被动模式。该公司设想，这就是 TradeMe 击败竞争对手的方法。

10. Forward looking on technology and regulations. Instead of being in perpetual reactive mode, the system must anticipate change. The company envisioned that this was how TradeMe would defeat the competitors.

11. 与外部系统良好集成。虽然与上一个目标有些关联，但这里的目标是实现以前费力的手动流程的高度自动化。

12. Integrate well with external systems. Although somewhat related to the previous objective, the objective here is to enable a high degree of automation over previously laborious manual processes.

13. 简化安全性。系统必须得到妥善保护，每个组件的设计都必须考虑到安全性。为了实现安全目标，开发团队必须将安全审计等安全活动引入软件生命周期并在架构中支持它。

14. Streamline security. The system must be properly secured, and literally every component must be designed with security in mind. To meet the security objective, the development team must introduce security activities such as security audits into the software life cycle and support it in the architecture.

使命宣言

Mission Statement

这可能令人惊讶，但阐明愿景（企业将获得什么）和目标（企业为何想要这个愿景）往往是不够的。人们通常过于纠结于细节而无法将各个点联系起来。因此，您还应该指定一个使命宣言（您将如何实现它）。TradeMe 的使命宣言是：

It may come as a surprise, but articulating the vision (what the business will receive) and the objectives (why the business wants the vision) is often insufficient. People are usually too mired in the details and cannot connect the dots. Thus, you should also specify a mission statement (how you will do it). The TradeMe Mission Statement was:

设计和构建一组软件组件，开发团队可以将其组装成应用程序和功能。

Design and build a collection of software components that the development team can assemble into applications and features.

这个使命声明故意没有将开发功能确定为使命。使命不是构建功能——使命是构建组件。现在，证明基于波动性的分解符合使命声明变得容易得多，因为所有点都是相互关联的：

This mission statement deliberately does not identify developing features as the mission. The mission is not to build features—the mission is to build components. It now becomes much easier to justify volatility-based decomposition that serves the mission statement because all the dots are connected:

愿景 → 目标 → 使命宣言 → 架构

Vision → Objectives → Mission Statement → Architecture

事实上，您刚刚迫使业务部门指示您设计正确的架构。这与典型的动态相反，在前者中，架构师恳求管理层避免功能分解。通过将架构与业务愿景、目标和使命陈述保持一致，可以更轻松地在整个业务中推动正确的架构。一旦您让他们就愿景、目标和使命陈述达成一致，他们就会站在您这边。如果您希望业务人员支持您的架构工作，您必须展示架构如何服务于业务。

In fact, you have just compelled the business to instruct you to design the right architecture. This is a reversal of the typical dynamics, in which the architect pleads with management to avoid functional decomposition. It is a lot easier to drive the correct architecture through the business by aligning the architecture with the business’s vision, its objectives, and the mission statement. Once you have them agree on the vision, the objectives, and then the mission statement, you have them on your side. If you want the business people to support your architecture effort, you must demonstrate how the architecture serves the business.

Trademe 词汇表

Trademe Glossary

开始编写词汇表的一个好方法是回答四个经典问题：“谁”、“什么”、“如何”和“在哪里”。您可以通过检查系统概述、用例和客户访谈记录（如果有）来回答这些问题。对于 TradeMe，这四个问题的答案如下：

A good way of starting a glossary is to answer the four classic questions of “who,” “what,” “how,” and “where.” You answer the questions by examining the system overview, the use cases, and customer interview notes, if you have any. For TradeMe, the answers to the four questions were as follows:

• WHO

  – 商人

  – 承包商

  – TradeMe 代表

  – 教育中心

  – 后台进程（即支付调度程序）

• Who

  –  Tradesmen

  –  Contractors

  –  TradeMe reps

  –  Education centers

  –  Background processes (i.e., scheduler for payment)

• 什么

  – 商人和承包商的会员资格

  – 建筑项目市场

  – 继续教育证书和培训

• What

  –  Membership of tradesmen and contractors

  –  Marketplace of construction projects

  –  Certificates and training for continuing education

• 如何

  – 搜索

  – 遵守法规

  – 访问资源

• How

  –  Searching

  –  Complying with regulations

  –  Accessing resources

• 在哪里

  – 本地数据库

  - 云

  – 其他系统

• Where

  –  Local database

  –  Cloud

  –  Other systems

回想一下第 3 章，您通常可以将这四个问题的答案映射到层，即使不是架构本身的组件。

Recall from Chapter 3 that you often can map the answers to the four questions to layers, if not to components of the architecture itself.

“什么”列表尤其有趣，因为它强烈暗示了可能的子系统或前面提到的泳道。在寻找易变区域时，您可以使用泳道和答案来播种和启动分解工作。这并不排除有额外的子系统，也不意味着这些子系统一定是所需的所有子系统——您总是根据易变性进行分解，如果“什么”不是易变的，那么它就不值得在架构中成为组件。此时，它提供的只是一个很好的起点来推理您的设计。

The list of the “what” is of particularly interest because it hints strongly at possible subsystems or the swim lanes mentioned previously. You can use the swim lanes and the answers to seed and initiate your decomposition effort as you look for areas of volatility. This does not preclude having additional subsystems or imply that these will necessarily be all the subsystems needed—you always decompose based on volatility, and if a “what” is not volatile, then it will not merit a component in the architecture. At this point all it provides is a nice starting point to reason about your design.

Trademe 波动领域

Trademe Areas of Volatility

分解的本质在于识别前几章中概述的波动区域。以下列表重点介绍了 TradeMe 的一些候选波动性以及设计团队考虑的因素：

The essence of the decomposition is in identifying the areas of volatility as outlined in the previous chapters. The following list highlights a few of the candidate volatilities for TradeMe and the factors the design team considered:

• 商人。这是系统中波动的领域吗？如果您需要为商人添加属性，那么很难说架构（即使是纯功能架构）会受到很大影响。换句话说，商人是可变的，但不是波动的。对于商人的任何属性子集（例如技能集），情况也是如此。也许商人本身并不是波动的。也许存在一种更通用的波动性，例如会员管理或法规，与商人有密切关系。以这种方式讨论波动性候选者甚至挑战它们很重要。如果您不能清楚地说明波动性是什么、为什么波动性以及波动性在可能性和影响方面带来什么风险，那么您需要进一步研究。将商人确定为波动性领域表明沿域线分解（见图5-12）。

• Tradesman. Is this an area of volatility in the system? It is hard to claim that the architecture, even a purely functional one, would suffer to a large extent if you need to add attributes to the tradesman. In other words, tradesman is variable but not volatile. This is also true for any subset of attributes of the tradesman (e.g., skill sets). Maybe the tradesman is not volatile in isolation. Perhaps there exists a more generic volatility, such as membership management or regulations, that has affinity with the tradesman. It is important to discuss the volatility candidates this way and even challenge them. If you cannot clearly state what the volatility is, why it is volatile, and what risk the volatility poses in terms of likelihood and effect, then you need to look further. Identifying tradesman as an area of volatility signals decomposition along domain lines (see Figure 5-12).

• 教育证书。认证过程是否不稳定？如果是，那么从业务和系统的角度来看，真正的波动性到底是什么？在这种情况下，波动性出现在将项目所需认证的法规与经过适当认证的商人相匹配的工作流程中。认证本身只是商人的一个属性。从企业的角度来看，认证管理永远是商人经纪的核心附加值的次要部分。

• Education certificates. Is the certification process volatile? If so, what exactly is the true volatility from the point of view of the business and the system? In this case, the volatility arises in the workflow of matching the regulations governing required certifications for projects with appropriately certified tradesman. The certification itself is just an attribute of the tradesman. From the business’s perspective, certification management will forever be secondary to the core added value of being a tradesmen brokerage.

• 项目。项目波动性是否值得拥有自己的管理器？AProject Manager表示项目上下文。AMarket Manager更好，因为系统需要管理的某些活动可能不需要正在运行的项目上下文来执行。例如，您可以要求市场提出匹配，而无需考虑特定项目，或者匹配可能需要涉及多个项目。也许为了留住有价值的商人，您希望向商人支付一笔定金，而不管任何项目。将项目识别为波动性表现为域分解。核心波动性是市场，而不是项目。

• Projects. Is project volatility deserving of its own Manager? A Project Manager implies a project context. A Market Manager is better because some activities that the system needs to manage may not require a context of a running project to execute. For example, you can ask the market to propose a match without having a specific project in mind, or maybe a match may require involving multiple projects. Perhaps to maintain a valuable tradesman you wish to pay the tradesman a retainer, irrespective of any project. Identifying projects as a volatility manifests as domain decomposition. The core volatility is the marketplace, not the projects.

提出某些波动性领域，然后检查最终架构，这并没有错。如果结果产生了蜘蛛网状的相互作用或不对称，那么设计就不太可能好。您可能会感觉到设计是否正确。

There is nothing wrong with suggesting certain areas of volatility, and then examining the resultant architecture. If the result produces a spiderweb of interactions or is asymmetric, then the design is unlikely to be good. You will probably sense whether the design is correct or not.

有时，波动区域可能位于系统之外。例如，虽然由于付款方式多种多样，付款很可能是一个波动区域，但 TradeMe 作为一个软件项目并不是要实施支付系统。付款是系统核心价值的附属品。系统可能会使用许多外部支付系统作为资源。资源可能是整个系统，每个系统都有自己的波动性，但这些超出了该系统的范围。

Sometimes an area of volatility may reside outside the system. For example, while payments may very well be a volatile area due to the various ways in which you could issue payments, TradeMe as a software project was not about implementing a payment system. The payments are ancillary to the core value of the system. The system will likely use a number of external payments systems as Resources. Resources may be whole systems, each with its own volatilities, but these are outside the scope of this system.

设计团队列出了以下足以影响架构的不稳定领域。该列表还标识了架构中与这些不稳定领域相对应的组件：

The design team produced the following list of areas volatile enough to affect the architecture. The list also identifies the corresponding components of the architecture that encapsulate the areas of volatility:

• 客户端应用程序。系统应允许多个不同的客户端环境以各自的速度独立发展。客户端迎合不同的用户（商人、承包商、市场代表或教育中心）或后台进程，例如定期与系统交互的计时器。这些客户端应用程序可能使用不同的 UI 技术、设备或 API（教育门户可能只是一个 API）；它们可以在本地或通过互联网访问（商人与代表）；它们可以连接或断开连接；等等。正如预期的那样，客户端与很多波动性相关。每个不稳定的客户端环境都封装在其自己的客户端应用程序中。

• Client applications. The system should allow several distinct client environments to evolve separately at their own pace. The clients cater to different users (tradesmen, contractors, marketplace reps, or education centers) or to background processes, such as a timer that periodically interacts with the system. These client applications may use different UI technologies, devices, or APIs (perhaps the education portal is a mere API); they may be accessed locally or across the Internet (tradesmen versus reps); they may be connected or disconnected; and so on. As expected, the clients are associated with a lot of volatility. Each one of these volatile client environments is encapsulated in its own Client application.

• 管理会员。增加或删除工匠和承包商的活动存在波动，甚至他们获得的福利或折扣也存在波动。会员管理会随着地区和时间的变化而变化。这些波动都包含在 中Membership Manager。

• Managing membership. There is volatility in the activities of adding or removing tradesmen and contractors, and even the benefits or discounts they get. Membership management changes across locales and over time. These volatilities are encapsulated in the Membership Manager.

• 费用。TradeMe的所有可能赚钱方式（结合交易量和价差）都包含在内Market Manager。

• Fees. All the possible ways TradeMe can make money, combining volume and spread, are encapsulated in the Market Manager.

• 项目。项目需求和规模不仅会发生变化，而且不稳定，会影响所需的行为。小型项目可能需要与大型项目不同的工作流程。系统将项目封装在 中Market Manager。

• Projects. Project requirements and size not only change but also are volatile and affect the required behavior. Small projects may require different workflows from large projects. The system encapsulates projects in the Market Manager.

• 争议。与人打交道时，最好的情况是产生误解；最坏的情况是发生彻头彻尾的欺诈。处理争议解决的波动性体现在以下几个方面Membership Manager。

• Disputes. When dealing with people, at best misunderstandings will arise; at worst outright fraud happens. The volatility in handling dispute resolution is encapsulated by the Membership Manager.

• 匹配和批准。这里涉及两个波动性。如何找到符合项目需求的工匠的波动性包含在 中Search Engine。搜索标准及其定义的波动性包含在 中Market Manager。

• Matching and approvals. Two volatilities come into play here. The volatility of how to find a tradesman that matches the project needs is encapsulated in the Search Engine. The volatility of search criteria and the definition thereof is encapsulated in the Market Manager.

• 教育。将培训课程与工匠匹配以及搜索可用课程或必修课程存在波动性。管理教育工作流程的波动性包含在 中Education Manager。搜索类和认证包含在 中Search Engine。 符合监管认证包含在 中Regulation Engine。

• Education. There is volatility in matching a training class to a tradesman and in searching for an available class or a required class. Managing the education workflow volatility is encapsulated in the Education Manager. Searching for classes and certifications is encapsulated in the Search Engine. Compliance with regulatory certification is encapsulated in the Regulation Engine.

• 法规。任何国家的法规都可能随着时间的推移而发生变化。此外，法规可能是公司内部的。这种波动性体现在 中Regulation Engine。

• Regulations. Regulations are likely to change in any given country as time goes by. In addition, the regulations can be internal to the company. This volatility is encapsulated in the Regulation Engine.

• 报告。系统需要遵守的所有报告和审计要求都包含在 中Regulation Engine。

• Reports. All the requirements of reporting and auditing with which the system needs to comply are encapsulated in the Regulation Engine.

• 本地化。两种不同的波动性与本地化有关。客户端的 UI 元素囊括了语言和文化的波动性。对于 TradeMe，利益相关者认为这是一个足够好的解决方案。在其他情况下，本地化可能具有足够强的波动性，值得拥有自己的子系统（例如，管理器、资源）。本地化甚至可能影响资源的设计。各国法规的波动性体现在中Regulation Engine。

• Localization. Two distinct volatilities relate to localization. UI elements of the Clients encapsulate the volatility in language and culture. For TradeMe, the stakeholders considered this a good enough solution. In other cases, localization could be a strong enough volatility that it would merit its own subsystem (e.g., Manager, Resources). Localization may even affect the design of the Resources. The volatility in regulations between countries is captured in the Regulation Engine.

• 资源。资源可能是外部系统（如支付）的门户，也可能是存储各种元素（如商人和项目列表）的门户。商店的确切性质是不稳定的，可能包括基于云的数据库、本地商店或整个其他系统。

• Resources. The Resources may be portals to external systems (such as payment) or store various elements such as lists of tradesman and projects. The exact nature of the store is volatile, potentially ranging from cloud-based database to a local store to a whole other system.

• 资源访问。ResourceAccess组件封装了访问资源的易变性，例如存储位置、类型和访问技术。ResourceAccess组件将原子业务动词（例如“支付”）转换为访问相关资源（例如存储和支付系统）。

• Resource access. ResourceAccess components encapsulate the volatility of accessing the Resources such as the location of the storage, its type, and access technology. The ResourceAccess components convert atomic business verbs such as “pay” (e.g., paying a tradesman) into accessing the relevant Resources such as storage and payment systems.

• 部署模型。部署模型具有易变性。有时数据无法离开某个地理区域，或者公司可能希望在云中部署部分或整个系统。这些易变性被封装在子系统和Message Bus实用程序的组成中。这种模块化可组合交互模式在系统操作概念中的优势将在后面介绍。

• Deployment model. The deployment model is volatile. Sometimes data cannot leave a geographic area, or the company may wish to deploy parts or whole systems in the cloud. These volatilities are encapsulated in the composition of the subsystems and the Message Bus utility. The advantages of this modular composable interaction pattern in the system operational concepts are described later.

• 身份验证和授权。系统可以通过多种方式对客户端进行身份验证，无论他们是用户还是其他系统，并且有多种表示凭证和身份的选项。授权几乎是开放式的，有多种存储角色或表示声明的方式。这些易变性都封装在Security Utility组件中。

• Authentication and authorization. The system can authenticate the Clients in a number of ways, whether they are users or even other systems, and there are multiple options for representing credentials and identities. Authorization is nearly open-ended, with many ways of storing roles or representing claims. These volatilities are encapsulated in the Security Utility component.

请注意，波动性区域与架构组件的映射并非 1:1。例如，前面的列表将三个波动性区域映射到Market Manager。回想一下第 3 章，管理器封装了一系列逻辑相关用例的波动性，而不仅仅是单个用例。在 的情况下Market Manager，这些市场用例是管理项目、将商人与项目匹配以及收取匹配费用。

Note that the mapping of areas of volatilities to components of the architecture is not 1:1. For example, the preceding list maps three areas of volatilities to the Market Manager. Recall from Chapter 3 that a Manager encapsulates the volatility of a family of logically related use cases, not just a single use case. In the case of the Market Manager, these market use cases are managing projects, matching tradesmen to projects, and charging the fees for the match.

静态架构

Static Architecture

图 5-14显示了该架构的静态视图。

Figure 5-14 shows the static view of the architecture.

实用工具

系统需要三个实用程序：Security、Message Bus和Logging。任何未来的实用程序（例如仪器）也将放在实用程序栏中。

The system requires three Utilities: Security, Message Bus, and Logging. Any future Utilities (e.g., instrumentation) would go in the Utility bar as well.

消息总线

Message Bus

消息总线仅仅是一个排队的发布/订阅（图 5-15）。发布到总线的任何消息都会广播给任意数量的订阅方。因此，消息总线提供通用的排队N：M通信，其中N和M可以是任何非负整数。如果消息总线发生故障，或者发布方断开连接，消息将在消息总线前排队，然后在恢复连接时进行处理。这提供了可用性和稳健性。如果订阅方发生故障或断开连接（例如移动设备），消息将发布到每个订阅者的私有队列中，并在订阅者可用时进行处理。如果发布的发布者和订阅者都已连接且可用，则消息是异步的。

A message bus is merely a queued Pub/Sub (Figure 5-15). Any message posted to the bus is broadcast to any number of subscribing parties. As such, a message bus provides for general-purpose, queued, N:M communication, where N and M can be any non-negative integers. If the message bus is down, or if the posting party becomes disconnected, messages are queued in front of the message bus, and then processed when connectivity is restored. This provides for availability and robustness. If the subscribing party is down or disconnected (such as a mobile device), the messages are posted to a private queue per subscriber, and are processed when the subscriber becomes available. If both the posting publisher and the subscriber are connected and available, then the messages are asynchronous.

消息总线技术的选择与架构关系不大，因此不在本书的讨论范围之内。但是，特定消息总线提供的特定功能可能会极大地影响实现的难易程度，因此选择正确的消息总线需要仔细考虑。并非所有消息总线都是一样的，包括来自名牌供应商的消息总线。至少，消息总线必须支持排队、复制消息和多播广播、标头和上下文传播、确保消息的发布和检索安全、离线工作、断开连接工作、传递失败处理、处理失败处理、毒药消息处理、事务处理、高吞吐量、服务层 API、多协议支持（尤其是非基于 HTTP 的协议）和可靠的消息传递。可能相关的可选功能包括消息过滤、消息检查、自定义拦截、检测、诊断、自动部署、与凭证存储的轻松集成以及远程配置。没有单一的消息总线产品能够提供所有这些功能。为了降低选择不当的风险，您应该从简单、易用、免费的消息总线开始，并首先使用该消息总线实现架构。这种策略可以让您更好地了解所需的品质和属性，并确定它们的优先级。只有这样，您才能选择真正满足您需求的最佳产品。

The choice of technology for the message bus has little to do with architecture and, therefore, is outside the scope of this book. However, specific features provided by a particular message bus may greatly affect ease of implementation, so choosing the right one requires careful consideration. Not all message buses are created equal, including those from brand-name vendors. At the very least, the message bus must support queuing, duplicating messages and multicast broadcasting, headers and context propagation, securing both posting and retrieving of messages, off-line work, disconnected work, delivery failure handling, processing failure handling, poison message handling, transactional processing, high throughput, a service-layer API, multiple-protocol support (especially non-HTTP-based protocols), and reliable messaging. Optional features that may be relevant include message filtering, message inspection, custom interception, instrumentation, diagnostics, automated deployment, easy integration with credentials stores, and remote configuration. No single message bus product will provide all these features. To mitigate the risk of choosing poorly, you should start with a plain, easy-to-use, free message bus, and implement the architecture initially with that message bus. This tactic allows you to better understand the desired qualities and attributes, and to prioritize them. Only then can you choose the best of breed that truly meets your needs.

在架构中添加消息总线并不意味着就不需要对通信模式施加架构约束。例如，您应该禁止通过总线进行客户端到客户端的通信。

Adding a message bus to your architecture does not eliminate the need to impose architectural constraints on the communications patterns. For example, you should disallow Client-to-Client communication across the bus.

作战概念

Operational Concepts

通过 TradeMe，所有客户和经理之间的所有通信都通过Message Bus 实用程序进行。图 5-16说明了这一操作概念。

With TradeMe, all communication between all Clients and all Managers takes place over the Message Bus Utility. Figure 5-16 illustrates this operational concept.

在这种交互模式中，客户端和子系统中的业务逻辑通过 相互解耦Message Bus。使用Message Bus通常支持以下操作概念：

In this interaction pattern, the Clients and the business logic in the subsystems are decoupled from each other by the Message Bus. Use of the Message Bus in general supports the following operational concepts:

• 所有通信都利用一种通用媒介（Message Bus）。它囊括了消息的性质、各方的位置以及通信协议。

• All communication utilizes a common medium (the Message Bus). This encapsulates the nature of the messages, the location of the parties, and the communication protocol.

• 用例发起者（例如客户端）和用例执行者（例如管理器）从来不直接交互。如果他们彼此不了解，他们可以单独发展，从而促进可扩展性。

• No use case initiator (such as Clients) and use case executioner (such as Managers) ever interact directly. If they are unaware of each other, they can evolve separately, which fosters extensibility.

• 多个并发客户端可以在同一用例中交互，每个客户端执行用例的一部分。客户端和系统之间没有锁步执行。这反过来又导致了时间线分离和时间线上组件的解耦。

• A multiplicity of concurrent Clients can interact in the same use case, with each performing its part of the use case. There is no lock-step execution across Clients and system. This, in turn, leads to timeline separation and decoupling of the components along the timeline.

• 高吞吐量是可能的，因为下面的队列Message Bus每秒可以接受大量消息。

• High throughput is possible because the queues underneath the Message Bus can accept a very large number of messages per second.

工作流管理器

Workflow Manager

使用方法，管理器可以封装业务工作流中的波动性。没有什么可以阻止您在管理器中简单地编写工作流，然后当工作流发生变化时，更改管理器中的代码。这种方法的问题在于，工作流中的波动性可能超出开发人员仅使用代码来跟上的能力（以时间和精力来衡量）。

With The Method, the Managers encapsulate the volatility in the business workflows. Nothing prevents you from simply coding the workflows in the Mangers and then, when the workflows change, changing the code in the Managers. The problem with this approach is that the volatility in the workflows may exceed the developers’ ability, as measured in time and effort, to catch up using just code.

TradeMe 中的下一个操作概念是使用工作流管理器。我在第 2 章讨论股票交易系统时暗示了这个概念，但本章将其编纂为另一种操作模式。TradeMe中的所有管理器都是工作流管理器。工作流管理器是一种服务，可让您创建、存储、检索和执行工作流。理论上，它只是另一个管理器。然而在实践中，这样的管理器几乎总是使用某种第三方工作流执行工具和工作流存储。对于每个客户端调用，工作流管理器不仅加载正确的工作流类型，还会加载具有特定状态和上下文的特定实例；执行工作流；并将其持久化回工作流存储。每次加载和保存工作流实例都支持长时间运行的工作流。管理器也不必在保持状态感知的同时与客户端保持任何类型的会话。同一工作流执行中同一用户的每次调用可以来自不同连接上的不同设备，并带有管理器应加载和执行的工作流实例的唯一 ID，以及有关客户端的信息，如其地址（例如 URI）。

The next operational concept in TradeMe is the use of workflow Managers. I hinted at this concept in Chapter 2 in the discussion of the stock trading system, but this chapter codifies it as another operational pattern. All Managers in TradeMe are workflow Managers. A workflow Manager is a service that enables you to create, store, retrieve, and execute workflows. In theory, it is just another Manager. In practice, however, such Managers almost always utilize some sort of third-party workflow execution tool and workflow storage. For each Client call, the workflow Manager loads not just the correct workflow type but also a specific instance of it, with a particular state and context; executes the workflow; and persists it back to the workflow store. Loading and saving the workflow instance each time supports long-running workflows. The Manager also does not have to maintain any kind of a session with the Client while remaining state-aware. Each call from the same user in the same workflow execution can come from a different device on a different connection and carries with it the unique ID of the instance of the workflow that the Manager should load and execute, as well as information about the client such as its address (e.g., URI).

要添加或更改功能，只需添加或更改相关经理的工作流程，而不一定需要个人的实施参与服务。这是将功能作为集成方面提供的一种清晰方式（如第 4 章所述），也是系统使命陈述的一个有形方面，可让您说明架构如何支持业务。

To add or change a feature, you simply add or change the workflows of the Managers involved, but not necessarily the implementation of the individual participating services. This is a clean way to provide features as aspects of integration (as discussed in Chapter 4) and is a tangible aspect of the mission statement for the system, allowing you to illustrate how the architecture supports the business.

当系统必须处理高波动性时，使用工作流管理器的真正必要性就出现了。使用工作流管理器，您只需编辑所需的行为并部署新生成的代码。此编辑的性质特定于您选择的工作流工具。例如，某些工具使用脚本编辑器，而其他工具使用看起来像活动图的可视化工作流并生成甚至部署工作流代码。

The real necessity for using a workflow Manager arises when the system must handle high volatility. With a workflow Manager, you merely edit the required behavior and deploy the newly generated code. The nature of this editing is specific to the workflow tool you choose. For example, some tools use script editors, whereas others use visual workflows that look like activity diagrams and generate or even deploy the workflow code.

您甚至可以（通过适当的保护措施）让产品所有者或最终用户编辑所需的行为。这大大缩短了交付功能的周期，并允许软件开发团队专注于核心服务，而不是追逐需求的变化。

You can even (with the right safeguards) have the product owners or the end users edit the required behavior. This drastically reduces the cycle time for delivering features and allows the software development team to focus on the core services as opposed to chasing changes in the requirements.

TradeMe 的业务需求证明了使用这种模式的合理性，因为使用由小型、分散的团队手工编写的编码不可能实现快速交付功能的目标。使用工作流管理器可以实现跨市场的高度定制，从而满足系统的另一个目标。

The business needs for TradeMe justified the use of this pattern because the objective of a quick turnaround for features is impossible to meet using hand-crafted coding by a small, thinly spread team. Use of workflow Manager enables a high degree of customization across markets, satisfying another objective for the system.

再次，请仔细评估此概念是否适用于您的特定情况。确保工作流程的波动程度能够证明额外的复杂性、学习曲线和开发流程的变化是合理的。

Again, evaluate carefully whether this concept is applicable to your particular case. Make sure the level of workflow volatility justifies the additional complexity, learning curves, and changes to the development process.

添加商人/承包商用例

Add Tradesman/Contractor Use Case

添加工匠/承包商用例涉及几个易变的领域：工匠（或承包商）客户端应用程序、添加成员的工作流程、法规遵从性以及使用的支付系统。您可以通过向图中添加泳道来重新排列和简化图 5-1中的用例，如图 5-17所示。

The Add Tradesman/Contractor use case involves several areas of volatility: the tradesman (or contractor) Client applications, the workflow of adding a member, compliance with regulations, and the payment system used. You can rearrange and simplify the use case from Figure 5-1 by adding swim lanes to the diagram, as shown in Figure 5-17.

图 5-17显示，用例的执行需要客户端应用程序和会员子系统之间的交互。这在图 5-18的实际调用链中很明显（添加承包商用例与承包商的应用程序相同，但Contractors Portal）。按照 TradeMe 的操作概念，在图 5-18中，客户端应用程序（在本例中，当Tradesman Portal会员直接申请时或当Marketplace App后端代表添加会员时）将请求发布到Message Bus。

Figure 5-17 shows that the execution of the use case requires interaction between a Client application and the membership subsystem. This is evident in the actual call chains of Figure 5-18 (the Adding Contractor use case is identical but with the contractor’s application, the Contractors Portal). Following the operational concepts of TradeMe, in Figure 5-18 the Client application (in this case, either the Tradesman Portal when the member is applying directly or the Marketplace App when the back-end rep is adding the member) posts the request to the Message Bus.

收到消息后，Membership Manager（即工作流管理器）将从工作流存储中加载适当的工作流。这将启动新的工作流或重新补充现有工作流以继续执行工作流执行。一旦工作流执行完请求，Membership Manager就会将消息发回 ，Message Bus指示工作流的新状态，例如已完成，或者可能指示其他某个管理器现在可以开始处理工作流，因为工作流处于新状态。客户端也可以监视Message Bus，并向用户更新他们的请求。Membership Manager咨询 ，Regulation Engine该管理器正在验证商人或承包商，将商人或承包商添加到商店，并通过 向客户端Members更新。Message Bus

Upon receiving the message, the Membership Manager (which is a workflow Manager) loads the appropriate workflow from the workflow storage. This either kicks off a new workflow or rehydrates an existing one to carry on with the workflow execution. Once the workflow has finished executing the request, the Membership Manager posts a message back into the Message Bus indicating the new state of the workflow, such as its completion, or perhaps indicating that some other Manager can start its processing now that the workflow is in a new state. Clients can monitor the Message Bus as well and update the users about their requests. The Membership Manager consults the Regulation Engine that is verifying the tradesman or contractor, adds the tradesman or contractor to the Members store, and updates the Clients via the Message Bus.

请求商人用例

Request Tradesman Use Case

请求商人用例包括两个关注领域：承包商和市场（图 5-19）。在初步验证请求后，此用例触发另一个用例，即匹配商人。

The Request Tradesman use case includes two areas of interest: the contractor and the market (Figure 5-19). After initial verification of the request, this use case triggers another use case, Match Tradesman.

调用链如图 5-20所示。客户端（例如Contractors Portal或 的内部用户）Marketplace App向总线发送一条消息，请求一名技工。Market Manager接收该消息。Market Manager加载与此请求相对应的工作流，并执行操作，例如咨询 了解Regulation Engine此请求可能有效的内容或使用技工请求更新项目。然后 可以将某人Market Manager发回给Message Bus请求工匠。这将触发匹配和分配工作流程，所有工作流程都在时间线上分开。

The call chains are depicted in Figure 5-20. Clients such as the Contractors Portal or the internal user of the Marketplace App post a message to the bus requesting a tradesman. The Market Manager receives that message. The Market Manager loads the workflow corresponding to this request, and performs actions such as consulting with the Regulation Engine about what may be valid for this request or updating the project with the request for a tradesman. The Market Manager can then post back to the Message Bus that someone is requesting a tradesman. This will trigger the matching and assignment workflows, all separated on the timeline.

匹配商人用例

Match Tradesman Use Case

Match Tradesman 核心用例涉及多个关注领域。首先是谁发起了触发匹配用例的 Tradesman 请求。发起者可以是客户（承包商或市场代表），如图5-20所示，但也可以是计时器或启动匹配工作流的任何其他子系统。其他关注领域包括市场、法规、搜索以及最终的会员资格，如图 5-21所示。

The Match Tradesman core use case involves multiple areas of interest. The first is who initiated the tradesman request that has triggered the match use case. That initiator could be a Client (a contractor or the marketplace reps), as in Figure 5-20, but it could also be a timer or any other subsystem that kicks off the match workflow. The other areas of interest are the market, regulations, search, and ultimately membership, as shown in Figure 5-21.

一旦你意识到法规和搜索都是市场要素，你就可以重构活动图，如图 5-22所示。这样可以轻松映射到你的子系统设计中。

Once you realize that regulations and search are all elements of the market, you can refactor the activity diagram to that shown in Figure 5-22. This enables easy mapping to your subsystems design.

图 5-23描述了相应的调用链。同样，此调用链与其他调用链是对称的，因为第一个操作是加载适当的工作流并执行它。调用链对Message Bus和的最后一次调用Membership Manager触发了 Assign Tradesman 用例。

Figure 5-23 depicts the corresponding call chain. Again, this call chain is symmetrical with other call chains, in the sense that the first action is to load the appropriate workflow and execute it. The last call of the call chain to the Message Bus and to the Membership Manager triggers the Assign Tradesman use case.

请注意此设计的可组合性。例如，假设公司确实需要在分析项目需求时处理剧烈波动。查找匹配的调用链允许将搜索与分析分开。您可以添加一个Analysis Engine来封装单独的分析算法集。企业甚至可以利用 TradeMe 来获取一些商业智能，以回答诸如“我们能做得更好吗？”之类的问题。例如，类似于图 5-23的调用链可用于更复杂的场景“分析 2016 年至 2019 年之间的所有项目”，并且组件的设计根本不需要改变。这些用例的数量可能是开放的，这就是重点：您有一个开放式的设计，可以扩展以实现任何这些未来场景，即真正的可组合设计。

Notice the composability of this design. For example, suppose the company really does need to handle acute volatility in analyzing the project’s needs. The call chain for finding a match allows for separating search from analysis. You would add an Analysis Engine to encapsulate the separate set of analysis algorithms. The business can even leverage TradeMe for some business intelligence to answer questions like “Could we have done things better?” For example, a call chain similar to Figure 5-23 could be used for the much more involved scenario of “Analyze all projects between 2016 and 2019” and the design of the components would not have to change at all. The number of these use cases is likely open, and that is the whole point: You have an open-ended design that can be extended to implement any of these future scenarios, a true composable design.

分配工匠用例

Assign Tradesman Use Case

分配商人用例涉及四个关注领域（图 5-24）：客户、会员、法规和市场。请注意，该用例与触发者无关，无论是实际的内部用户还是来自另一个子系统的总线请求消息。例如，在自动匹配和分配的情况下，匹配商人用例可以触发分配用例作为工作流的直接延续。

The Assign Tradesman use case involves four areas of interest (Figure 5-24): client, membership, regulations, and market. Note that the use case is independent of who triggered it, whether an actual internal user or just a request message off the bus from another subsystem. For example, the Match Tradesman use case could trigger the assignment use case as a direct continuation of the workflow in the case of automatic match and assignment.

再次，重构活动图之后，很容易映射到子系统（图5-25）。

Again, after refactoring the activity diagram, it is easy to map to subsystems (Figure 5-25).

与所有先前的调用链一样，图 5-26显示了Membership Manager执行最终将工匠分配到项目的工作流。这是 和 之间的协作工作Membership Manager，Market Manager它们各自管理各自的子系统。请注意， 并不Membership Manager知道 ，Market Manager它只是向总线发送一条消息。Market Manager接收该消息并根据其内部工作流更新项目。Market Manager反过来， 可能会向 发送另一条消息以Message Bus触发另一个用例，例如发布项目报告或为承包商开具账单，或几乎任何事情。这就是“消息即应用程序”设计模式的全部内容：逻辑“分配”消息在服务之间穿梭，在传递过程中触发本地行为。客户端还可以监视Message Bus，并可能通知用户分配正在进行中。

As with all previous call chains, Figure 5-26 shows how the Membership Manager is executing the workflow that ultimately leads to assigning the tradesman to the project. This is a collaborative work between the Membership Manager and the Market Manager, with each managing its respective subsystem. Note that the Membership Manager is unaware of the Market Manager” it just posts a message to the bus. The Market Manager receives that message and updates the project according to its internal workflow. The Market Manager may, in turn, post another message to the Message Bus to trigger another use case, such as issuing a report on the project, or billing for the contractor, or pretty much anything. This is what the Message Is the Application design pattern is all about: The logical “assignment” message weaves its way between the services, triggering local behaviors as it goes. The Client can also monitor the Message Bus and may advise the user that the assignment is in progress.

终止商人用例

Terminate Tradesman Use Case

在之前的用例中，初始图泳道包括法规区域，该区域随后被合并到会员子系统中。由于这是一种重复出现的模式，图 5-9显示了 Terminate Tradesman 用例的重构图。该图仍然提供了足够的区分，以便清晰地映射到设计中。

In the previous use cases, the initial diagram swim lanes included the regulations area, which was subsequently consolidated into the membership subsystem. Since this was such a recurring pattern, Figure 5-9 shows the refactored diagram for the Terminate Tradesman use case. This diagram still provides enough differentiation to allow for clear mapping to the design.

图 5-27显示了终止商人的调用链。Market Manager启动终止工作流程并通知Membership Manager终止事宜。

Figure 5-27 shows the call chain for terminating a tradesman. The Market Manager initiates the termination workflow and notifies the Membership Manager of the termination.

任何错误情况或偏离“正确路径”都会添加一条虚线灰色箭头，从后端Membership Manager指向Message Bus最终返回到客户端。图 5-28是演示此交互的序列图，其中没有ResourceAccess服务和Resources之间的调用。

Any error condition or deviation from the “happy path” would add a dashed gray arrow from the Membership Manager back to the Message Bus and ultimately back to the client. Figure 5-28 is a sequence diagram demonstrating this interaction, without the calls between the ResourceAccess services and the Resources.

最后，图 5-27中的调用链图（或图 5-28中的序列图）假设终止用例在项目完成时触发，承包商终止指派的商人。但它也可以由商人从 向 发布消息来触发Tradesman Portal，Membership Manager这将导致调用链以相反的方向流动（Membership Manager流向Market Manager并继续流向客户端应用程序）。这再次证明了设计的多功能性。

Finally, the call chain diagram in Figure 5-27 (or the sequence diagram of Figure 5-28) assumes the termination use case is triggered when a project is completed, and the contractor terminates the assigned tradesmen. But it can also be triggered by the tradesman posting a message from the Tradesman Portal to the Membership Manager, which would cause the call chain to flow in the opposite direction (Membership Manager to Market Manager and on to the Client apps). Again, this is a testimony to the versatility of the design.

支付商人用例

Pay Tradesman Use Case

其余用例与迄今为止描述的用例的交互和设计模式密切相关，因此这里只对它们进行简要描述。还请注意调用链中的高度自相似性或对称性。图 5-6显示了 Pay Tradesman 用例，其验证调用链如图 5-29所示。

The rest of the use cases closely follow the interactions and design pattern of the use cases described thus far, so only brief descriptions of them appear here. Also note the high degree of self-similarity or symmetry in the call chains. Figure 5-6 showed the Pay Tradesman use case, and its validating call chain is in Figure 5-29.

与之前的调用链不同，付款由客户已启用的调度程序或计时器触发。调度程序与实际组件分离，不了解系统内部情况：它所做的只是向总线发送消息。实际付款是在PaymentAccess更新Payments商店并访问外部支付系统（TradeMe 的资源）时进行的。

Unlike the previous call chains, the payment is triggered by a scheduler or timer that the customer has already in service. The scheduler is decoupled from the actual components and has no knowledge of the system internals: All it does is post a message to the bus. The actual payment is made by PaymentAccess when updating the Payments store and accessing an external payment system, a Resource to TradeMe.

创建项目用例

Create Project Use Case

在另一个简单的用例中，Market Manager通过执行相应的工作流来响应创建项目的请求（参见图 5-30和图 5-7中的用例图）。无论这需要多少步骤，或涉及多少错误，工作流管理器模式的性质都允许根据需要进行尽可能多的排列。

In another simple use case, the Market Manager responds to the request to create a project by executing a corresponding workflow (see Figure 5-30 and the use case diagram in Figure 5-7). Regardless of how many steps this takes, or how many errors are involved, the nature of the workflow Manager pattern allows for as many permutations as needed.

关闭项目用例

Close Project Use Case

关闭项目用例涉及和Market Manager（Membership Manager参见图 5-31和图 5-8中的用例）。TradeMe 再次通过这两个主要抽象之间的相互作用完成了这项任务；交互与图 5-27中显示的交互相同。

The Close Project use case involves both the Market Manager and the Membership Manager (see Figure 5-31 and the use case in Figure 5-8). Again, TradeMe accomplishes this task with the interplay between these two major abstractions; the interaction is identical to that shown in Figure 5-27.

项目设计和项目健全性

Project Design and Project Sanity

项目设计可以让你发现黑暗的角落——也就是说，提前了解项目的真实范围。项目设计迫使管理者在工作开始前仔细考虑，认识到意想不到的关系和限制，代表所有活动，并识别构建系统的几种选择。它允许组织确定是否要完成该项目。毕竟，如果实际成本和持续时间将超过可接受的限度，那么为什么一开始就开始工作，而一旦资金或时间用完，项目就会被取消？

Project design allows you to shed light on dark corners—that is, to have up-front visibility on the true scope of the project. Project design forces managers to think through work before it begins, to recognize unsuspected relationships and limits, to represent all activities, and to recognize several options for building the system. It allows the organization to determine whether it even wants to get the project done. After all, if the true cost and duration will exceed the acceptable limits, why start the work in the first place, only to have the project canceled once you run out of money or time?

一旦项目设计到位，您便可以避免常见的成本赌博、开发死亡行军、对项目成功的痴心妄想以及代价高昂的反复试验。在工作开始后，精心设计的项目还为决策者评估和思考拟议变更对进度和预算的影响奠定了基础。

Once project design is in place, you eliminate the commonplace gambling with costs, development death marches, wishful thinking about project success, and horrendously expensive trials and errors. After work commences, a well-designed project also lays the foundation for decision makers to evaluate and think through the effect of a proposed change on the schedule and the budget.

组装说明

Assembly Instructions

项目设计涉及的不仅仅是正确的决策。项目设计还充当系统组装说明。打个比方，你会购买一套设计精良的宜家家具，却没有组装说明手册吗？无论这件物品多么舒适或方便，只要想到要猜测数十个销钉、螺栓、螺钉和板子的位置和顺序，你就会感到畏缩。

Project design involves much more than just proper decision making. Project design also serves as the system assembly instructions. To use an analogy, would you buy a well-designed IKEA furniture set without the assembly instructions booklet? Regardless of how comfortable or convenient the item is, you would recoil at the mere thought of trying to guess where each of the dozens of pins, bolts, screws, and plates go, and in which order.

您的软件系统比家具复杂得多，但架构师通常认为开发人员和项目经理可以随心所欲地组装系统，并在过程中解决问题。这种临时方法显然不是组装系统的最有效方法。正如您将在下一章中看到的那样，项目设计改变了这种情况，因为要知道交付系统需要多长时间以及需要多少成本，唯一的方法是先弄清楚如何构建它。因此，每个项目设计选项都带有自己的一套组装说明。

Your software system is significantly more complex than furniture, yet often architects presume developers and projects managers can just go about assembling the system, figuring it out as they go along. This ad hoc approach is clearly not the most efficient way of assembling the system. As you will see in the next chapters, project design changes the situation, since the only way to know how long it will take and how much it will cost to deliver the system is to figure out first how you will build it. Consequently, each project design option comes with its own set of assembly instructions.

需求层次

Hierarchy of Needs

1943 年，亚伯拉罕·马斯洛发表了一部关于人类行为的重要著作，即马斯洛需求层次理论。1^马斯洛根据人类需求的相对重要性对其进行了排序，并指出，只有当一个人满足了较低层次的需求后，他才会对满足较高层次的需求产生兴趣。这种层次方法可以描述另一类复杂的事物——软件项目。图 6-1以金字塔的形式显示了软件项目的需求层次结构。

In 1943, Abraham Maslow published a pivotal work on human behavior, known as Maslow’s hierarchy of needs.¹ Maslow ranked human needs based on their relative importance and suggested that only once a person has satisfied a lower-level need could that person develop an interest in satisfying a higher-level need. This hierarchal approach can describe another category of complex beings—software projects. Figure 6-1 shows a software project’s hierarchy of needs in the shape of a pyramid.

1. A.H.马斯洛，《人类动机理论》，《心理学评论》 50，第4期（1943年）：370-396。

1. A. H. Maslow, “A Theory of Human Motivation,” Psychological Review 50, no. 4 (1943): 370–396.

项目需求可分为五个层次：物理、安全、可重复性、工程和技术。

The project needs can be classified into five levels: physical, safety, repeatability, engineering, and technology.

1. 物质需求。这是项目需求金字塔中最低的一层，与物质生存有关。就像人必须有空气、食物、水、衣服和住所一样，项目必须有工作场所（即使是虚拟的）和可行的商业模式。项目必须有计算机来编写和测试代码，以及指派人员执行这些任务。项目必须有适当的法律保护。项目不得侵犯现有的外部知识产权 (IP)，但也必须保护自己的知识产权。

2. Physical. This is the lowest level in the project pyramid of needs, dealing with physical survival. Much as a person must have air, food, water, clothing, and shelter, a project must have a workplace (even a virtual one) and a viable business model. The project must have computers to write and test the code, as well as people assigned to perform these tasks. The project must have the right legal protection. The project must not infringe on existing external intellectual property (IP), yet must also protect its own IP.

3. 安全性。一旦满足了物质需求，项目必须有足够的资金（通常以分配的资源形式）和足够的时间来完成工作。工作本身必须在可接受的风险下进行——不能太安全（因为低风险项目可能不值得做）也不能太冒险（因为高风险项目可能会失败）。简而言之，项目必须相当安全。项目设计在需求金字塔的这个层次上进行。

4. Safety. Once the physical needs are satisfied, the project must have adequate funding (often in the form of allocated resources) and enough time to complete the work. The work itself must be performed with acceptable risk—not too safe (because low-risk projects are likely not worth doing) and not too risky (because high-risk projects will likely fail). In short, the project must be reasonably safe. Project design operates at this level in the pyramid of needs.

5. 可重复性。项目可重复性描述了开发组织一次又一次成功交付的能力，是控制和执行的基础。它确保如果您计划并承诺一定的时间表和成本，您将兑现这些承诺。可重复性体现了团队和项目的可信度。要获得可重复性，您必须管理需求，管理和跟踪项目相对于计划的进度，采用单元和系统测试等质量控制措施，拥有有效的配置管理系统，并积极管理部署和运营。

6. Repeatability. Project repeatability describes the development organization’s ability to deliver successfully time and again, and is the foundation for control and execution. It assures that if you plan for and commit to a certain schedule and cost, you will deliver on those commitments. Repeatability captures the credibility of the team and the project. To gain repeatability, you must manage requirements, manage and track the project’s progress against the plan, employ quality control measures such as unit and system testing, have an effective configuration management system, and actively manage deployment and operations.

7. 工程。一旦确保了项目工作的可重复性，软件项目就可以首次将注意力转向软件工程的诱人方面。这包括架构和详细设计、质量保证活动（如根本原因分析和纠正（在系统层面））以及使用强化操作程序的预防工作。本书的第一部分专门讨论系统设计，它就处于金字塔的这一层。

8. Engineering. Once the repeatability of the project effort is secured, the software project can, for the first time, turn its attention to the enticing aspects of software engineering. This includes architecture and detail design, quality assurance activities such as root cause analysis and correction (on a systemic level), and preventive work using hardened operating procedures. The first part of this book, which was devoted to system design, operates at this level of the pyramid.

9. 技术。这一层级包括开发技术、工具、方法、操作系统以及相关的核心技术方面。这是需求金字塔的顶峰，只有当较低的需求得到充分满足时，它才能充分发挥其潜力。

10. Technology. At this level are development technology, tools, methodology, operating systems, and related hard-core technical aspects. This is the very pinnacle of the pyramid of needs, and it can express itself to its full potential only once the lower needs are fully addressed.

在需求层次中，较高层次的需求服务于较低层次的需求。例如，根据马斯洛的观点，食物是比就业更低层次的需求，但大多数人工作是为了吃饭，而不是吃饭是为了工作。同样，技术服务于工程需求（例如建筑），工程需求服务于安全需求（项目设计提供的需求）。这也意味着，按时间顺序，你必须先设计系统；只有这样，你才能设计项目来构建它。

In a hierarchy of needs, higher-level needs serve the lower-level needs. For example, according to Maslow, food is a lower-level need than employment, yet most people work so that they can eat, as opposed to eat so that they can work. Similarly, the technology serves the engineering needs (such as the architecture), and the engineering needs serve the safety needs (those that project design provides). It also means that chronologically you have to design the system first; only then can you design the project to build it.

您可以通过列出典型软件项目成功所需的所有必要因素来验证金字塔。然后，您可以对它们进行优先排序、排序，最后将它们分组到需求类别中。

You can validate the pyramid by listing all necessary ingredients for success of a typical software project. You then prioritize, sort, and finally group them into categories of needs.

作为此过程中的一项实验，请考虑以下两个项目。第一个项目的设计紧密耦合，维护成本高，重用程度低，并且难以扩展。但是，有足够的时间来完成工作，并且项目人员配备适当。第二个项目具有令人惊叹的架构，它是模块化的、可扩展的和可重用的；满足所有要求；并且面向未来。但是，团队人手不足，即使有人员可用，也没有足够的时间来安全地开发系统。问问自己：您想参与哪个项目？

As an experiment in this process, consider the following two projects. The first has a tightly coupled design, a high cost of maintenance, and a low level of reuse, and is difficult to extend. However, there is adequate time to perform the work, and the project is properly staffed. The second project has an amazing architecture that is modular, extensible, and reusable; addresses all the requirements; and is future-proof. However, the team is understaffed, and even if the people were available, there is not enough time to safely develop the system. Ask yourself: Which project you would like to be part of?

答案毫无疑问是第一个项目。因此，项目设计在需求金字塔中的排名必须低于架构（即更基础）。许多软件项目失败的一个典型原因是需求金字塔倒置。想象一下图 6-1颠倒过来。开发团队几乎只关注技术、框架、库和平台；几乎没有在架构和设计上花费任何资金；完全忽略了时间、成本和风险等基本问题。这使得需求金字塔不稳定，这样的项目失败也就不足为奇了。通过使用项目设计工具投资金字塔的安全级别，您可以分层项目的需求，提供稳定上层的基础，并推动项目走向成功。

The answer is unequivocally the first project. Consequently, project design must rank lower (i.e., be more foundational) in the pyramid of needs than architecture. A classic reason for failure for many software projects is an inverted pyramid of needs. Imagine Figure 6-1 turned on its head. The development team focuses almost exclusively on technology, frameworks, libraries, and platforms; spends next to nothing on architecture and design; and completely ignores the fundamental issues of time, cost, and risk. This makes the pyramid of needs unstable, and it is small wonder that such projects fail. By investing in the safety level of the pyramid using the tools of project design, you stratify the needs of the project, provide the foundation that stabilizes the upper levels, and drive the project to success.

报告成功

Reporting Success

本书的第 1 部分阐述了一个通用的设计规则：特性始终是集成而非实现的方面。因此，早期的服务中都没有特性。在某个时候，您将集成到足以开始看到特性。我将这个点称为系统。系统不太可能出现在项目的最后，因为可能会有一些额外的结束活动，如系统测试和部署。系统通常出现在最后，因为它需要大多数服务以及客户端。当使用方法时，这意味着只有在管理器、引擎、资源访问和实用程序内部集成后，您才能支持客户端所需的行为。

Part 1 of this book stated a universal design rule: Features are always and everywhere aspects of integration, not implementation. As such, there are no features in any of the early services. At some point you will have integrated enough to start seeing features. I call that point the system. The system is unlikely to appear at the very end of the project since there may be some additional concluding activities such as system testing and deployment. The system typically appears toward the end because it requires most of the services as well as the clients. When using The Method, this means only once you have integrated inside the Managers, the Engines, the ResourceAccess, and the Utilities can you support the behaviors that the Clients require.

虽然系统是集成的产物，但并非所有集成都发生在管理器内部。有些集成发生在管理器完成之前（例如引擎集成ResourceAccess），有些集成发生在管理器之后（例如客户端和管理器之间）。还可能存在显式集成活动，例如针对模拟器开发服务客户端，然后将客户端与实际服务集成。

While the system is the product of the integration, not all the integration happens inside the Managers. Some integration happens before the Managers are complete (such as the Engines integrating ResourceAccess) and some integration happens after the Managers (such as between the Clients and the Managers). There might also be explicit integration activities, such as developing a client of a service against a simulator and then integrating the client with the real service.

系统只在项目结束时出现的问题在于管理层的反对。大多数负责管理软件开发的人都不理解本书中的设计概念，只是想要功能。他们永远不会停下来想一想，如果一个功能可以尽早快速出现，那么它就不会为企业或客户增加太多价值，因为公司或团队没有在该功能上花费太多精力。通常，管理层使用功能作为衡量进度和成功的指标，并倾向于取消没有进展的病态项目。因此，该项目面临着严重的风险：它可能完全按计划进行，但由于系统只在最后出现，如果项目根据功能来报告进度，那么它就是在要求取消。解决方案很简单：

The problem with the system appearing only toward the end of the project is pushback from management. Most people tasked with managing software development do not understand the design concepts in this book and simply want features. They would never stop to think that if a feature can appear early and quickly, then it does not add much value for the business or the customers because the company or the team did not spend much effort on the feature. Usually, management uses features as the metric to gauge progress and success, and tends to cancel sick projects that do not show progress. As such, the project faces a serious risk: It could be perfectly on schedule but because the system only appears at the end, if the project bases its progress report on features, it is asking to be canceled. The solution is simple:

永远不要根据功能来报告进度。始终根据集成来报告进度。

Never base progress reports on features. Always base progress reports on integration.

基于方法的项目在项目过程中会进行大量集成。这些集成规模小且可行。因此，项目有可能不断传出好消息，建立信任并避免取消。

A Method-based project performs a lot of integration along the project. These integrations are small and doable. As a result, there is the potential for a constant stream of good news coming out of the project, building trust and avoiding cancellation.

建筑师，不是建筑师

Architect, Not Architects

架构师需要花时间收集和分析需求，确定核心用例和易变性领域，并进行系统和项目设计。虽然设计本身并不耗时（架构师通常可以在一两周内设计系统和项目），但可能需要几个月的时间才能达到架构师可以设计系统和项目的程度。

The architect will need to spend time gathering and analyzing the requirements, identifying the core use cases and the areas of volatility, and producing the system and the project design. While the design itself is not time-consuming (the architect can usually design both the system and the project in a week or two), it may take several months to get to the point that the architect can design the system and the project.

大多数经理都会对花费三四个月的时间进行设计或完全跳过设计感到不安。他们可能希望通过让更多架构师参与来加速设计工作。然而，需求分析和架构是需要深思熟虑、耗时的活动。分配更多架构师对这些活动的监督并不能加速这些活动，反而会使情况变得更糟。架构师通常是自信的高级人员，习惯于独立工作。指派多个架构师只会导致他们相互竞争，而不是在系统和项目设计蓝图上竞争。

Most managers will recoil both at spending some three or four months on design and at skipping design entirely. They may wish to accelerate the design effort by having more architects participate. However, requirements analysis and architecture are contemplative, time-consuming activities. Assigning more architects to these activities does not expedite them at all, but instead will make matters worse. Architects are typically senior self-confident personnel, used to working independently. Assigning multiple architects only results in them contesting with each other, rather than in system and project design blueprints.

解决多架构师冲突的一种方法是任命一个设计委员会。不幸的是，任命一个委员会来监督它是毁掉任何东西的最可靠方法。另一种选择是分割系统并指派每个架构师设计一个特定的区域。如果采用这种方式，系统最终可能会变成奇美拉——一种希腊神话中的野兽，有狮子的头、龙的翅膀、牛的前腿和山羊的后腿。虽然奇美拉的每个部分都设计精良，甚至经过高度优化，但奇美拉在尝试的任何事情上都表现不佳：它飞得不如龙，跑得不如狮子，拉得不如牛，爬得不如山羊。奇美拉缺乏设计完整性——当多个架构师设计系统时也是如此，每个人都负责自己的部分。

One way of resolving the multiple architects conflict is to appoint a design committee. Unfortunately, the surest way of killing anything is to appoint a committee to oversee it. Another option is to carve up the system and assign each architect a specific area to design. With this option, the system is likely to end as a Chimera—a mythological Greek beast that has the head of a lion, the wings of a dragon, the front legs of an ox, and the hind legs of a goat. While each part of the Chimera is well designed and even highly optimized, the Chimera is inferior at anything it attempts: It does not fly as well as a dragon, run as fast as a lion, pull as much as an ox, or climb as well as a goat. The Chimera lacks design integrity—and the same is true when multiple architects design the system, each responsible for their part.

单一架构师对于设计完整性而言绝对至关重要。您可以将此观察结果扩展到一般规则，即实现设计完整性的唯一方法是让单一架构师负责设计。反之亦然：如果没有一个人负责设计并能够从头到尾可视化设计，则系统将不具备设计完整性。

A single architect is absolutely crucial for design integrity. You can extend this observation to the general rule that the only way to allow for design integrity is to have a single architect own the design. The opposite is also true: If no single person owns the design and can visualize it cover-to-cover, the system will not have design integrity.

此外，由于有多个架构师，因此没有人负责中间环节、跨子系统甚至跨服务的设计方面。因此，没有人对整个系统设计负责。当没有人对某件事负责时，这件事就永远不会完成，或者最多只能做得很差。

Additionally, with multiple architects no one owns the in-betweens, the cross-subsystem or even cross-services design aspects. As a result, no one is accountable for the system design as a whole. When no one is accountable for something, it never gets done, or at best is done poorly.

如果只有一位架构师负责，那么该架构师将负责系统设计。归根结底，负责任是赢得管理层尊重和信任的唯一途径。尊重总是源于负责任。当没有人负责任时，就像一群架构师的情况一样，管理层本能地对架构师及其设计工作只会嗤之以鼻。

With a single architect in charge, that architect is accountable for the system design. Ultimately, being accountable is the only way to earn the respect and trust of management. Respect always emerges out of accountability. When no one is accountable, as is the case with a group of architects, management intuitively has often nothing but scorn for the architects and their design effort.

核心团队

The Core Team

尽管架构师对项目至关重要，但架构师不能孤立地工作。在第一天，项目必须有一个核心团队。核心团队由三个角色组成：项目经理、产品经理和架构师。这些是逻辑上的角色，可能对应也可能不对应三个人。如果没有对应，您可能会看到同一个人既是架构师又是项目经理，或者一个项目有多个产品经理。

As vital as the architect is to the project, the architect cannot work in isolation. On day 1, the project must have a core team in place. The core team consists of three roles: project manager, product manager, and architect. These are logical roles and may or may not map to three individuals. When they do not, you may see the same person as both the architect and the project manager, or a project with several product managers.

大多数组织和团队都有这些角色，但他们使用的职位名称可能不同。我将这些角色定义如下：

Most organizations and teams have these roles, but the job titles they use may be different. I define these roles as follows:

• 项目经理。项目经理的工作是保护团队不受组织的影响。大多数组织，即使是小组织，也会产生太多噪音。如果这些噪音进入开发团队，就会使团队陷入瘫痪。优秀的项目经理就像一道防火墙，可以阻挡噪音，只允许经过批准的沟通通过。项目经理跟踪进度并向管理层和其他项目经理报告状态，协商条款，并处理跨组织约束。在内部，项目经理将工作项目分配给开发人员，安排活动，并确保项目按时、按预算、按质量进行。除了项目经理之外，组织中的任何人都不应分配工作活动或向开发人员询问状态。

• The project manager. The job of the project manager is to shield the team from the organization. Most organizations, even small ones, create too much noise. If that noise makes its way into the development team, it can paralyze the team. A good project manager is like a firewall, blocking the noise, allowing only sanctioned communication through. The project manager tracks progress and reports status to management and other project managers, negotiates terms, and deals with cross-organization constraints. Internally, the project manager assigns work items to developers, schedules activities, and keeps the project on schedule, on budget, and on quality. No one in the organization other than the project manager should assign work activity or ask for status from developers.

• 产品经理。产品经理应该囊括客户。客户也是一个持续的噪音源。产品经理充当客户的代理。例如，当架构师需要明确所需的行为时，架构师不应该追逐客户；相反，产品经理应该提供答案。产品经理还解决客户之间的冲突（通常表现为相互排斥的需求）、协商需求、定义优先级，并传达关于什么是可行的以及在什么条件下可行的期望。

• The product manager. The product manager should encapsulate the customers. Customers are also a constant source of noise. The product manager acts as a proxy for the customers. For example, when the architect needs to clarify the required behaviors, the architect should not chase customers; instead, the product manager should provide the answers. The product manager also resolves conflicts between customers (often expressed as mutually exclusive requirements), negotiates requirements, defines priorities, and communicates expectations about what is feasible and on what terms.

• 架构师。架构师是技术经理，担任项目的设计负责人、流程负责人和技术负责人。架构师不仅设计系统，还要监督整个开发过程。架构师需要与产品经理合作完成系统设计，与项目经理合作完成项目设计。虽然与产品经理和项目经理的合作至关重要，但架构师要对这两项设计工作负责。作为流程负责人，架构师必须确保团队逐步构建系统，遵循系统和项目设计，并坚持不懈地保证质量。作为技术负责人，架构师通常必须决定完成技术任务的最佳方式（做什么），而将细节（如何做）留给开发人员。这需要持续的实践指导、培训和评审。

• The architect. The architect is the technical manager, acting as the design lead, the process lead, and the technical lead of the project. The architect not only designs the system, but also sees it through development. The architect needs to work with the product manager to produce the system design and with the project manager to produce the project design. While the collaboration with both the product manager and the project manager is essential, the architect is held responsible for both of these design efforts. As a process lead, the architect has to ensure the team builds the system incrementally, following the system and the project design with a relentless commitment to quality. As a technical lead, the architect often has to decide on the best way of accomplishing technical tasks (the what-to-do) while leaving the details (the how-to-do) to developers. This requires continuous hands-on mentoring, training, and reviews.

核心团队定义中最明显的遗漏可能就是开发人员。开发人员（和测试人员）是跨项目来来去去的临时资源——这是本章在讨论活动安排和资源分配时重新讨论的一个非常重要的点。

Perhaps the most glaring omission from this definition of the core team are developers. Developers (and testers) are transient resources that come and go across projects—a very important point that this chapter revisits as part of the discussion of scheduling activities and resource assignment.

与开发人员不同，核心团队会一直参与整个项目，因为项目从头到尾都需要这三个角色。但是，这些角色在项目中的作用会随着时间的推移而变化。例如，项目经理从与利益相关者协商转变为提供状态报告，产品经理从收集需求转变为执行演示。架构师从设计系统和项目转变为提供持续的技术和流程领导，例如在服务级别进行设计和代码审查以及解决技术冲突。

Unlike developers, the core team stays throughout the project since the project needs all three roles from beginning to end. However, what these roles do in the project changes over time. For example, the project manager shifts from negotiating with stakeholders to providing status reports, and the product manager shifts from gathering requirements to performing demos. The architect shifts from designing the system and the project to providing ongoing technical and process leadership, such as conducting design and code reviews at the service level and resolving technical conflicts.

计划，不是计划

Plans, Not Plan

项目设计的结果是一组计划，而不是单个计划。如上一章所述，项目计划不是时间和成本的单一坐标。构建任何系统总是有多种可能的方式，只有一种选择才能提供时间、成本和风险的正确组合。架构师可能会倾向于简单地询问管理层项目的设计参数是什么，然后只设计那个单一选项。问题是，管理人员通常不会说出他们的意思，也不会真正表达他们的意思。

The result of project design is a set of plans, not a single plan. As described in the previous chapter, the project plan is not a single coordinate of time and cost. There are always multiple possible ways of building any system, and only one option will offer the right combination of time, cost, and risk. The architect may be tempted to simply ask management what the design parameters of the project are and just design that single option. The problem is that managers often do not say what they mean or mean what they say.

例如，考虑一个 10 人年的项目，即所有活动的工作量总和为 10 人年的项目。假设管理层要求以成本最低的方式构建系统。这样的项目将让一个人工作 10 年，但管理层不太可能愿意等待 10 年。现在假设管理层要求以最快的方式构建系统。想象一下，可以通过让 3650 人工作 1 天（甚至让 365 人工作 10 天）来构建相同的系统。管理层不太可能在这么短的时间内雇用这么多人。同样，管理层永远不会要求以最安全的方式构建系统（因为任何值得做的事情都需要风险，而安全的项目不值得做）或故意选择最冒险的方式开展项目。

For example, consider a 10-man-year project—that is, a project where the sum of effort across all activities is 10 man-years. Suppose management asks for the least costly way of building the system. Such a project would have one person working for 10 years, but management is unlikely to be willing to wait 10 years. Now suppose that management asks for the quickest possible way to build the system. Imagine it is possible to build the same system by engaging 3650 people for 1 day (or even 365 people for 10 days). Management is unlikely to hire so many people for such short durations. Similarly, management will never ask for the safest way of building the system (because anything worth doing requires risk, and safe projects are not worth doing) or knowingly go for the riskiest way of doing the project.

软件开发计划审查

Software Development Plan Review

解决管理层真正想要什么的模糊性的唯一方法是提供一系列好的选项供他们选择，每个选项都是时间、成本和风险的可行组合。你可以在一个非正式的称为“喂我/杀了我”的专门会议上向管理层介绍这些选项。顾名思义，此会议的目的是让管理层选择其中一个项目设计方案并投入所需资源（“喂我”路线）。选项之一始终是不做这个项目（“杀了我”路线）。正式的会议名称应该是软件开发计划评审，或 SDP 评审。如果你的流程没有 SDP 评审点也没关系：只需召开会议（没有经理可以拒绝主题为“软件开发计划评审”的会议请求）。

The only way to resolve the ambiguity about what management really wants is to present a buffet of good options from which to choose, with each option being a viable combination of time, cost, and risk. You present these options to management in a dedicated meeting unofficially called the Feed Me/Kill Me meeting. As the name implies, the purpose of this meeting is for management to choose one of the project design options and commit the required resources (the “Feed Me” route). One of the options is always that of not doing the project (the “Kill Me” route). Officially, the name of the meeting should be the Software Development Plan Review, or SDP review. It makes no difference if your process does not have an SDP review point: Just call a meeting (no manager can refuse a meeting request whose subject line is “Software Development Plan Review”).

一旦确定了所需的选项，管理层必须签署 SDP 文件。该文件现在成为您项目的人寿保险单，因为只要您不偏离计划的参数，就没有理由取消您的项目。这确实需要适当的跟踪（如附录 A所述）和项目管理。

Once the desired option is identified, management must literally sign off on the SDP document. This document now becomes your project’s life insurance policy because, as long as you do not deviate from the plan’s parameters, there is no reason to cancel your project. This does require proper tracking (as described in Appendix A) and project management.

如果没有可行的选择，那么你需要做出正确的决定——在这种情况下，就是终止项目。一个注定失败的项目，一个从一开始就没有得到足够时间和资源的项目，对任何人都没有好处。该项目最终会耗尽时间或金钱，或两者兼而有之，组织不仅会浪费资金和时间，还会浪费将这些资源投入另一个可行项目的机会成本。参与一个永远没有机会的项目对核心团队成员的职业生涯也有不利影响。由于你只有几年的时间来取得成就并向前迈进，所以每个项目都必须有意义，成为你的荣誉。花一两年时间在一个失败的横向行动上会限制你的职业前景。在开发开始之前终止这样的项目对所有相关人员都有好处。

If no option is palatable, then you need to drive the right decision—in this case, killing the project. A doomed project, a project that from inception did not receive adequate time and resources, will do no one any good. The project will eventually run out of time or money or both, and the organization will have wasted not just the funds and time but the opportunity cost of devoting these resources to another doable project. It is also detrimental to the careers of the core team members to be on a project that never has a chance. Since you have only a few years to make your mark and move ahead, every project must count and be a feather in your cap. Spending a year or two on a sideways move that failed will limit your career prospects. Killing such a project before development starts is beneficial for all involved.

设计和团队效率

Design and Team Efficiency

当使用 1:1 的比例将服务分配给开发人员时，服务之间的交互与开发人员之间的交互是同构的。考虑图 7-1。

When using 1:1 assignments of services to developers, it follows that the interaction between the services is isomorphic to the interaction between the developers. Consider Figure 7-1.

服务之间的关系、交互和通信决定了开发人员之间的关系和交互。当使用 1:1 分配时，系统的设计就是团队的设计。

The relationship between the services, their interactions and communication, dictates the relationships and interactions between the developers. When using 1:1 assignment, the design of the system is the design of the team.

接下来，考虑图 7-2。虽然服务的数量及其大小与图 7-1相比没有变化，但没有人可以说这是一个好的设计。

Next, consider Figure 7-2. While the number of services and their size has not changed from Figure 7-1, no one could claim it is a good design.

良好的系统设计力求将模块之间的交互数量减少到最低限度——与图 7-2中的情况完全相反。如图 7-1所示的松耦合系统设计已将交互数量降至最低，以至于删除一个交互会使系统无法运行。

A good system design strives to reduce the number of interactions between the modules to their bare minimum—the exact opposite of what happens in Figure 7-2. A loosely coupled system design such as that in Figure 7-1 has minimized the number of interactions to the point that removing one interaction makes the system inoperable.

图 7-2中的设计显然是紧耦合的，它也描述了团队的运作方式。比较一下图 7-1和图 7-2中的团队。你更愿意加入哪个团队？图 7-2中的团队是一个高压力、脆弱的团队。团队成员可能有领土意识并抵制变化，因为每个变化都会产生连锁反应，扰乱他们的工作和其他人的工作。他们花费大量时间开会解决问题。相比之下，图 7-1中的团队可以在本地解决问题并控制它们。每个团队成员几乎都独立于其他成员，不需要花费太多时间协调工作。简而言之，图 7-1中的团队比图 7-2中的团队效率高得多。因此，拥有更好系统设计的团队更有可能在紧迫的最后期限前完成任务。

The design in Figure 7-2 is clearly tightly coupled, and it also describes the way the team operates. Compare the teams from Figure 7-1 and Figure 7-2. Which team would you rather join? The team in Figure 7-2 is a high-stress, fragile team. The team members are likely territorial and resist change because every change has ripple effects that disrupt their work and the work of everybody else. They spend an inordinate amount of time in meetings to resolve their issues. In contrast, the team in Figure 7-1 can address issues locally and contain them. Each team member is almost independent from the others and does not need to spend much time coordinating work. Simply put, the team in Figure 7-1 is far more efficient than the team in Figure 7-2. As a result, the team with the better system design has far better prospects of meeting an aggressive deadline.

最后这一点至关重要：大多数经理只是口头上支持系统设计，因为架构的好处（可维护性、可扩展性和可重用性）是长远利益。对于面临资源匮乏和时间紧迫的严酷现实的经理来说，未来的利益无济于事。如果有什么帮助的话，经理应该尽可能减少工作范围，以满足最后期限。由于系统设计对当前目标没有帮助，经理将放弃对设计的任何有意义的投资。遗憾的是，这样做，经理失去了履行承诺的所有机会，因为满足紧迫期限的唯一方法是采用世界一流的设计，从而产生最高效的团队。在努力获得管理层对你的设计工作的支持时，展示设计如何帮助实现眼前的目标。长期利益将由此产生。

This last observation is paramount: Most managers just pay lip service to system design because the benefits of architecture (maintainability, extensibility, and reusability) are down-the-road benefits. Future benefits do not help a manager who is facing the harsh reality of scant resources and a tight schedule. If anything, it behooves the manager to reduce the scope of work as much as possible to meet the deadline. Since system design is supposedly not helping with the current objectives, the manager will throw overboard any meaningful investment in design. Sadly, by doing so, the manager loses all chance of meeting the commitments, because the only way to meet an aggressive deadline is with a world-class design that yields the most efficient team. When striving to get management support for your design effort, show how design helps with the immediate objective. The long-term benefits will flow out of that.

任务连续性

Task Continuity

分配服务（或 UI 开发等活动）时，尽量保持任务连续性，即分配给每个人的任务之间的逻辑连续性。通常，此类任务分配遵循服务依赖关系图。如果服务A依赖于服务B，则分配A给开发人员B。一个优点是A已经熟悉的开发人员B需要更少的启动时间。保持任务连续性的一个重要但经常被忽视的优势是项目和开发人员的成功标准是一致的。开发人员有动力在完成工作时做好充分的工作，B以避免在需要做工作时遭受损失A。完美的任务连续性几乎不可能实现，但它应该是目标。

When assigning services (or activities such as UI development), try to maintain task continuity, a logical continuation between tasks assigned to each person. Often, such task assignments follow the service dependency graph. If service A depends on service B, then assign A to the developer of B. One advantage is that the A developer who is already familiar with B needs less ramp-up time. An important, yet often overlooked advantage of maintaining task continuity is that the project and the developer’s win criteria are aligned. The developer is motivated to do an adequate job on B to avoid suffering when it is time to do A. Perfect task continuity is hardly ever possible, but it should be the goal.

最后，在分配任务时要考虑开发人员的个人技术倾向。例如，让安全专家设计 UI、让数据库专家实现业务逻辑或让初级开发人员实现消息总线或诊断等实用程序可能效果不佳。

Finally, take the developers’ personal technical proclivities into account when making assignments. For example, it will likely not work well to have the security expert design the UI, to have the database expert implement the business logic, or to have junior developers implement the utilities such as message bus or diagnostics.

经典错误

Classic Mistakes

正如刚才提到的，人们倾向于高估或低估，以试图弥补不确定性。这两者都是项目成功的关键。

As just mentioned, people tend to overestimate and underestimate in an attempt to compensate for uncertainty. Both of these are deadly when it comes to project success.

根据帕金森定律，高估永远行不通。2^例如，如果你给开发人员三周时间来完成一项需要两周才能完成的工作，那么开发人员将有两周的时间不做这项工作，然后闲置一周。相反，开发人员将花三周时间从事这项工作。由于实际工作只占用了三周中的两周时间，因此在额外的一周时间里，开发人员将从事镀金工作——添加没有人需要或想要的花哨功能、方面和功能，而这些功能和功能并不是设计的一部分。这种镀金工作大大增加了任务的复杂性，而增加的复杂性大大降低了成功的可能性。因此，开发人员需要四到六周的时间才能完成最初的任务。项目中的其他开发人员原本希望在三周后收到代码，但现在他们的工作也耽误了。此外，现在团队拥有的代码模块可能已经存在多年，并且跨越了多个版本，但它比最初应该有的复杂得多。

Overestimation never works because of Parkinson’s law.² For example, if you give a developer three weeks to perform a two-week activity, the developer will simply not work on it for two weeks and then be idle for a week. Instead, the developer will work on the activity for three weeks. Since the actual work consumed only two of those three weeks, in the extra week the developer will engage in gold plating—adding bells and whistles, aspects, and capabilities that no one needs or wants, and that were not part of the design. This gold plating significantly increases the complexity of the task, and the increased complexity drastically reduces the probability of success. Consequently, the developer labors for four or six weeks to finish the original task. Other developers in the project, who expect to receive the code after three weeks, are now delayed, too. Furthermore, the team now owns, perhaps for years and across multiple versions, a code module that is needlessly more complex than what it should have been in the first place.

2. Cyril N. Parkinson，《帕金森定律》，《经济学人》 （1955 年 11 月 19 日）。

2. Cyril N. Parkinson, “Parkinson’s Law,” The Economist (November 19, 1955).

低估同样会导致失败。毫无疑问，给开发人员两天时间来完成为期两周的编码活动将使任何金光闪闪的事情都化为泡影。问题是开发人员会试图快速而粗略地完成活动，偷工减料，无视所有已知的最佳实践。这就像要求外科医生快速而粗略地为您做手术或要求承包商快速而粗略地建造房屋一样明智。

Underestimation guarantees failure just as well. Undoubtedly, giving a developer two days to perform a two-week coding activity will preclude any gold plating. The problem is that the developer will try to do the activity quick-and-dirty, cutting corners and disregarding all known best practices. This is as sensible as asking a surgeon to operate on you quick-and-dirty or a contractor to build a house quick-and-dirty.

遗憾的是，任何复杂的任务都不能快速完成。取而代之的是快速干净和脏乱慢两种选择。由于开发人员缺乏软件开发中的所有最佳实践，从测试到详细设计再到文档，开发人员现在正试图以最糟糕的方式执行任务。因此，假设工作正确完成，开发人员将不会在原本可能花费的两周时间内完成该活动，而会因为质量低下和复杂性增加而花费四到六周（或更长时间）。与高估一样，项目中其他开发人员原本希望在预定的两天后完成代码，但结果却被大大推迟了。此外，团队现在必须拥有一个以最糟糕的方式完成的代码模块，也许需要数年时间，跨越多个版本。

Sadly, there is no quick-and-dirty with any intricate task. Instead, the two options are quick-and-clean and dirty-and-slow. Because the developer is missing all the best practices in software development, from testing to detailed design to documentation, the developer is now trying to perform the task in the worst possible way. Consequently, the developer will not work on the activity for the nominal two weeks it could have taken, assuming the work was performed correctly, but will work on it for four or six (or more) weeks due to the low quality and increased complexity. As with overestimation, other developers in the project who expected the code after the scheduled two days are much delayed. Furthermore, the team now has to own, perhaps for years and across multiple versions, a code module that is done the worst possible way.

成功概率

虽然这些结论可能符合常识，但许多人忽视了这些典型错误的严重程度。图 7-3以定性方式绘制了成功概率与估计的关系。例如，考虑一个为期 1 年的项目。在适当的架构和项目设计下，项目的正常估计时间为 1 年，如图 7-3N中的点所示。如果给这个项目一天的时间，成功的概率是多少？一周？一个月？显然，如果估计足够激进，成功的概率为零。6 个月呢？虽然为期 1 年的项目在 6 个月内完成的概率极低，但并不是零，因为也许会发生奇迹。如果估计为 11 个月零 3 周，成功的概率实际上非常高，对于 11 个月来说也相当高。但是，项目不太可能在 9 个月内完成。因此，在正常估计的左侧是一个临界点，成功概率在此以非线性方式大幅提高。同样，这个为期 1 年的项目可以持续 13 个月，甚至 14 个月也是合理的。但如果你给这个项目 18 或 24 个月的时间，你肯定会失败，因为帕金森定律会发挥作用：工作会扩大以填满分配的时间，项目会因为复杂性的增加而失败。因此，在正常估计的右侧存在另一个临界点，成功的可能性再次以非线性方式崩溃。

While these conclusions may make common sense, what many miss is the magnitude of these classic mistakes. Figure 7-3 plots in a qualitative manner the probability of success as a function of the estimation. For example, consider a 1-year project. With proper architecture and project design, the project’s normal estimation is 1 year, indicated by point N in Figure 7-3. What would be the probability of success if you give this project a day? A week? A month? Clearly, with sufficiently aggressive estimations, the probability of success is zero. How about 6 months? While the probability of a 1-year project completing in 6 months is extremely low, it is not zero because maybe a miracle will happen. The probability of success if you estimate at 11 months and 3 weeks is actually very high, and it is also fairly high for 11 months. However, it is unlikely the project can complete in 9 months. Therefore, to the left of the normal estimation is a tipping point where the probability of success drastically improves in a nonlinear way. Similarly, this 1-year project could last 13 months, and even 14 months is reasonable. But if you give this project 18 or 24 months, you will surely kill it because Parkinson’s law will kick in: Work will expand to fill the allotted time, and the project will fail due to the increased complexity. Therefore, another tipping point exists to the right of the normal estimation, where the probability of success again collapses in a nonlinear way.

图 7-3说明了良好的名义估计至关重要，因为它们以非线性的方式最大化了成功概率。过去，当你低估和高估时，你很可能会伤害自己和他人。这些不仅是常见的经典错误，而且是根本性错误。

Figure 7-3 illustrates the paramount importance of good nominal estimations because they maximize the probability of success, in a nonlinear way. In the past, you were likely to hurt yourself and others when you both underestimated and overestimated. These are not just common, classic mistakes—they are cardinal mistakes.

估算技术

Estimation Techniques

尽管数十年来，软件行业已经出现了一套行之有效的估算技术，并且已在多个其他行业中广泛使用，但软件行业在估算方面的糟糕记录仍然存在。我还没有看到一个团队在正确地进行估算的同时，项目设计和承诺也偏离了目标。本节并不试图回顾所有这些技术，而是重点介绍我多年来发现的一些最简单、最有效的想法和技术。

The poor track record with estimations in the software industry persists even though a decent set of effective estimation techniques have been available for decades and across multiple other industries. I have yet to see a team that has practiced estimations correctly and was also off the mark with their project design and commitments. Instead of trying to review all of these techniques, this section highlights some of the ideas and techniques I have found over the years to be the most simple and effective.

PERT 估算

专门处理高不确定性的估算技术之一是项目评估与审查技术 (PERT)。3对于^每项活动，您都要提供三个估算：最乐观、最悲观和最有可能。最终估算由以下公式提供：

One estimation technique dealing specifically with high uncertainly is part of Program Evaluation and Review Technique (PERT).³ For every activity, you provide three estimations: the most optimistic, the most pessimistic, and the most likely. The final estimation is provided by this formula:

3. https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique

3. https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique

在哪里：

where:

• E是计算出的估计值。

• E is the calculated estimation.

• O是乐观的估计。

• O is the optimistic estimation.

• M是最有可能的估计。

• M is the most likely estimation.

• P是悲观的估计。

• P is the pessimistic estimation.

例如，如果某项活动的乐观估计为 10 天，悲观估计为 90 天，最可能估计为 25 天，则该活动的 PERT 估计时间为 33.3 天：

For example, if an activity has an optimistic estimation of 10 days, a pessimistic estimation of 90 days, and a most likely estimation of 25 days, the PERT estimation for it would be 33.3 days:

总体项目估算

Overall Project Estimation

对整个项目进行估算主要用于项目设计验证，但在启动项目设计时也会很有用。完成详细的项目设计后，将其与总体项目估算进行比较。两者不必完全匹配，但应该一致并相互验证。例如，如果详细项目设计为 13 个月，而总体项目估算为 11 个月，则详细项目设计有效。但如果总体估算为 18 个月，则至少有一个数字是错误的，您必须调查差异的来源。在处理前期约束很少的项目时，您也可以利用总体项目估算。这种干净的画布项目有很多未知数，因此很难设计。您可以使用总体项目估算来反向工作以将某些活动纳入其中，作为启动项目设计过程的一种方式。

Estimating the project as a whole is useful primarily for project design validation, but can also be beneficial when initiating project design. When you finish the detailed project design, compare it to the overall project estimation. The two need not match perfectly but should be congruent and validate each other. For example, if the detailed project design was 13 months and the overall project estimation was 11 months, then the detailed project design is valid. But if the overall estimation was 18 months, then at least one of these numbers is wrong, and you must investigate the source of the discrepancy. You can also utilize the overall project estimation when dealing with a project with very few up-front constraints. Such a clean canvas project has a great deal of unknowns, making it difficult to design. You can use the overall project estimation to work backward to box in certain activities as a way of initiating the project design process.

活动估计

Activity Estimations

项目设计从项目中各个活动的预计持续时间开始。在估计各个活动之前，您必须准备一份项目所有活动的详细清单，包括编码和非编码活动。从某种意义上说，即使是这份活动清单也是对实际活动集的估计，因此，减少不确定性的相同原理在这里也适用。避免专注于系统架构所指示的结构编码活动的诱惑，积极地在水线以下查看冰山的全部范围。花时间寻找活动，并请其他人编制该清单，以便您可以将其与自己的清单进行比较。让同事审查、批评和质疑您的活动清单。您可能会对自己实际错过的内容感到惊讶。

You start the project design with the estimated duration of the individual activities in the project. Before you estimate individual activities, you must prepare a meticulous list of all activities in the project, both coding and noncoding activities alike. In a way, even that list of activities is an estimation of the actual set of activities, so the same rationale about reducing uncertainties holds true here. Avoid the temptation to focus on the structural coding activities indicated by the system architecture, and actively look below the waterline at the full extent of the iceberg. Invest time in looking for activities, and ask other people to compile that list so you could compare it with your own list. Have colleagues review, critique, and challenge your list of activities. You may be surprised by what you actually missed.

由于准确度高于精确度，因此最佳实践是在任何活动估算中始终使用 5 天的时间。需要 1 或 2 天的活动不应成为计划的一部分。需要 3 或 4 天的活动始终估计为 5 天。活动持续 5、10、15、20、25、30 或 35 天。估计为 40 天或更长时间的活动可能适合分解为较小的活动以减少不确定性。每个活动使用 5 天的时间可以使项目在周边界上很好地对齐，并减少活动前后几周的部分浪费。这种做法也符合现实生活——从来没有任何活动在星期五开始。

Since accuracy is superior to precision, a best practice is to always use a quantum of 5 days in any activity estimation. Activities that take 1 or 2 days should not be part of the plan. Activities that are 3 or 4 days are always estimated at 5 days. Activities are either 5, 10, 15, 20, 25, 30, or 35 days long. Activities estimated at 40 or more days may be good candidates to break down into smaller activities to reduce the uncertainty. Using 5 days for each activity aligns the project nicely on week boundaries and reduces waste of parts of weeks before or after an activity. This practice also matches real life—no activity has ever started on a Friday.

不确定性的减少甚至对常规规模的活动也有好处。强迫自己和其他人将每项活动分解为除编码之外的任务，例如学习曲线、测试客户端、安装、集成点、同行评审和文档。同样，通过避免专注于编码并检查未来的全部工作范围，您可以大大减少对单个活动估计的不确定性。

The reduction in uncertainty benefits even regular-size activities. Force yourself and others to break down each activity into tasks in addition to coding, such as learning curves, test clients, installation, integration points, peer reviews, and documentation. Again, by avoiding focusing on coding and examining the full scope of the work ahead, you greatly reduce the uncertainty of individual activity estimations.

项目网络

Project Network

您可以将项目中的活动以图形方式排列到网络图中。网络图显示项目中的所有活动及其依赖关系。首先，从调用链在系统中传播的方式得出活动依赖关系。对于已验证的每个用例，您应该有一个调用链或序列图，显示系统构建块之间的某些交互如何支持每个用例。如果一个图有Client A调用Manager A，而第二个图有Client A调用Manager B，则Client A依赖于Manager A和Manager B。通过这种方式，您可以系统地发现架构组件之间的依赖关系。图 7-4显示了基于方法的示例架构中代码模块的依赖关系图。

You can graphically arrange the activities in the project into a network diagram. The network diagram shows all activities in the project and their dependencies. You first derive the activity dependencies from the way the call chains propagate through the system. For each of the use cases you have validated, you should have a call chain or sequence diagram showing how some interaction between the system’s building blocks supports each use case. If one diagram has Client A calling Manager A and a second diagram has Client A calling Manager B, then Client A depends on both Manager A and Manager B. In this way, you systematically discover the dependencies between the components of the architecture. Figure 7-4 shows the dependency chart of the code modules in a sample Method-based architecture.

图 7-4中显示的依赖关系图有几个问题。首先，它结构性很强，缺少所有非结构化编码和非编码活动。其次，它在图形上很庞大，对于较大的项目来说，视觉上会变得过于拥挤和难以管理。第三，您应该避免将活动分组在一起，就像图中的实用程序一样。

The dependency chart shown in Figure 7-4 has several problems. First, it is highly structural and is missing all the nonstructural coding and noncoding activities. Second, it is graphically bulky and with larger projects would become visually too crowded and unmanageable. Third, you should avoid grouping activities together, as is the case with the Utilities in the figure.

您应该将图 7-4中的图表转换为图 7-5中所示的详细抽象图表。该图表现在包含所有活动，包括编码和非编码活动，例如架构和系统测试。您可能还想添加一个侧面图例来标识活动，以便于查看。

You should turn the diagram in Figure 7-4 into the detailed abstract chart shown in Figure 7-5. That chart now contains all activities, coding and noncoding alike, such as architecture and system testing. You may want to also add a side legend identifying the activities for easy review.

活动时间

单凭一项活动的工作量估计并不能确定该活动何时完成：对其他活动的依赖关系也会发挥作用。因此，完成每项活动的时间是该活动的工作量估计加上在项目网络中到达该活动所需的时间的乘积。到达某项活动的时间，或准备开始从事该活动所需的时间，是所有通向该活动的网络路径中时间的最大值。用更正式的术语来说，i方式，您可以使用以下递归公式计算完成项目活动的时间：

The effort estimation for an activity alone does not determine when that activity will complete: Dependencies on other activities also come into play. Therefore, the time to finish each activity is the product of the effort estimation for that activity plus the time it takes to get to that activity in the project network. The time to get to an activity, or the time it takes to be ready to start working on the activity, is the maximum of time of all network paths leading to that activity. In a more formal manner, you calculate the time for completing activity i in the project with this recursive formula:

在哪里：

where:

• Ti是完成活动的时间i。

• Ti is the time for completing activity i.

• Ei是活动的工作量估算i。

• Ei is the effort estimation for activity i.

• n是直接导致活动的活动数量i。

• n is the number of activities leading directly to activity i.

前面每项活动的时间都以相同的方式解决。使用回归，您可以从项目中的最后一项活动开始，找到网络中每项活动的完成时间。例如，考虑图 7-6中的活动网络。

The time for each of the preceding activities is resolved the same way. Using regression, you can start with the last activity in the project and find the completion time for each activity in the network. For example, consider the activity network in Figure 7-6.

在图 7-6的图中，活动5是最后一个活动。因此，定义完成活动时间的回归表达式集5为：

In the diagram in Figure 7-6, activity 5 is the last activity. Thus, the set of regression expressions that define the time to finish activity 5 are:

请注意，完成活动的时间5取决于先前活动的工作量估计，也取决于网络拓扑。例如，如果图 7-6中的所有活动持续时间相等，则：

Note that the time to finish activity 5 depends on the effort estimation of the previous activities as much as it depends on the network topology. For example, if all the activities in Figure 7-6 are of equal duration, then:

但是，如果除活动之外的所有活动都6估计为 5 天，并且活动6估计为 20 天，那么：

However, if all activities except activity 6 are estimated at 5 days, and activity 6 is estimated at 20 days, then:

虽然您可以手动计算小型网络（如图 7-6所示）的活动时间，但对于大型网络，这种计算很快就会失控。计算机擅长处理回归问题，因此您应该使用工具（例如 Microsoft Project 或电子表格）来计算活动时间。

While you could manually calculate the activity times for small networks such as Figure 7-6, this calculation quickly gets out of hand with large networks. Computers excel at regression problems, so you should use tools (such as Microsoft Project or a spreadsheet) to calculate activity times.

关键路径

The Critical Path

通过计算活动时间，您可以确定活动网络中最长的可能路径。在这种情况下，最长的路径意味着持续时间最长的路径，而不一定是活动数量最多的路径。例如，图 7-7中的项目网络有 17 项活动，每项活动的预计持续时间都不同（图 7-7中的数字只是活动 ID；未显示持续时间）。

By calculating the activity times, you can identify the longest possible path in the network of activities. In this context, the longest path means the path with greatest duration, not necessarily the one with the greatest number of activities. For example, the project network in Figure 7-7 has 17 activities, each of different estimated duration (the numbers in Figure 7-7 are just the activity IDs; durations are not shown).

根据对每项活动和依赖关系的工作量估计，使用前面给出的公式并从活动开始17，网络中最长的路径以粗体显示。网络中最长的路径称为关键路径。您应该使用不同的颜色或粗线在网络图中突出显示关键路径。计算关键路径是回答构建系统需要多长时间的问题的唯一方法。

Based on the effort estimation for each activity and the dependencies, using the formula given earlier and starting from activity 17, the longest path in the network is shown in bold. That longest path in the network is called the critical path. You should highlight the critical path in your network diagrams using a different color or bold lines. Calculating the critical path is the only way to answer the question of how long it will take to build the system.

由于关键路径是网络中最长的路径，因此它也代表最短的项目持续时间。关键路径上的任何延迟都会延迟整个项目并危及您的承诺。

Because the critical path is the longest path in the network, it also represents the shortest possible project duration. Any delay on the critical path delays the entire project and jeopardizes your commitments.

任何项目都不可能加速超越其关键路径。换句话说，您必须沿着其关键路径构建系统，以最快的方式构建系统。对于任何项目而言，无论技术、架构、开发方法、开发流程、管理风格和团队规模如何，都是如此。

No project can ever be accelerated beyond its critical path. Put another way, you must build the system along its critical path to build the system the quickest possible way. This is true in any project, regardless of technology, architecture, development methodology, development process, management style, and team size.

在任何涉及多个活动且由多人参与的项目中，您都会拥有一个包含关键路径的活动网络。关键路径并不关心您是否承认它；它就在那里。如果没有关键路径分析，开发人员沿着关键路径构建系统的可能性几乎为零。以这种方式工作可能会慢得多。

In any project with multiple activities on which multiple people are working, you will have a network of activities with a critical path. The critical path does not care if you acknowledge it or not; it is just there. Without critical path analysis, the likelihood of developers building the system along the critical path is nearly zero. Working this way is likely to be substantially slower.

分配资源

Assigning Resources

在项目设计期间，架构师会将抽象资源（例如Developer 1）分配给每个项目设计选项。只有在决策者选择了特定的项目设计选项之后，项目经理才能分配实际资源。由于关键路径上的任何延迟都会导致项目延迟，因此项目经理应始终首先将资源分配给关键路径。您应该更进一步，始终将最佳资源分配给关键路径。我所说的“最佳”是指最可靠、最值得信赖的开发人员，他们不会失败。避免犯下经典错误，即首先将开发人员分配到高知名度但非关键的活动，或客户或管理层最关心的活动。首先将开发资源分配给非关键活动无助于加速项目进度。减慢关键路径的速度绝对会减慢项目进度。

During project design, the architect assigns abstract resources (such as Developer 1) to each of the project design options. Only after the decision makers have chosen a particular project design option can the project manager assign actual resources. Since any delay in the critical path will delay the project, the project manager should always assign resources to the critical path first. You should take matters a step further by always assigning your best resources to the critical path. By “best,” I mean the most reliable and trustworthy developers, the ones who will not fail to deliver. Avoid the classic mistake of first assigning developers to high-visibility but noncritical activities, or to activities that the customer or management care the most about. Assigning development resources first to noncritical activities does nothing to accelerate the project. Slowing down the critical path absolutely slows down the project.

人员分布

Staffing Distribution

项目所需的人员配备不会随时间而变化。一开始，您只需要核心团队。一旦管理层选择了项目设计方案并批准了该项目，您就可以添加开发人员和测试人员等资源。

The required staffing for your project is not constant with time. At the beginning, you need only the core team. Once management selects a project design option and approves the project, you can add resources such as developers and testers.

由于依赖关系和关键路径，并非所有资源都需要一次性投入。同样，并非所有资源都会统一退役。核心团队始终需要投入，但开发人员不应该一直投入到项目的最后一天。理想情况下，您应该在项目开始时随着越来越多的活动成为可能而逐步引入开发人员，并在项目结束时逐步淘汰开发人员。

Not all resources are needed all at once due to the dependencies and the critical path. Much the same way, not all resources are retired uniformly. The core team is required throughout, but developers should not be needed through the last day of the project. Ideally, you should phase in developers at the beginning of the project as more and more activities become possible, and phase out the developers toward the end of the project.

这种逐步投入和逐步淘汰资源的方法有两个显著的​​优势。首先，它避免了许多软件项目所经历的“丰收或饥荒”周期。即使您拥有项目所需的平均人员水平，您也可能会在项目的某个部分人手不足，而在另一部分人手过剩。这种闲置或大量加班的周期令人沮丧，而且效率极低。其次（也是更重要的），逐步投入资源提供了实现规模经济的可能性。如果您的组织中有多个项目，那么您可以安排它们，让开发人员在逐步投入另一个项目的同时逐步退出一个项目。以这种方式工作可以使生产力提高百分之百，这就是经典的“用更少的资源做更多的事情”。

This approach of phasing in and phasing out resources has two significant advantages. First, it avoids the feast-or-famine cycles experienced by many software projects. Even if you have the required average level of staffing for the project, you could be understaffed in one part of the project and overstaffed in another part. These cycles of idleness or intense overtime are demoralizing and very inefficient. Second (and more importantly), phasing resources offers the possibility of realizing economy of scale. If you have several projects in the organization, then you could arrange them such that developers are always phasing out of one project while phasing into another. Working this way yields a hundreds of percent increase in productivity, the classic “doing much more with less.”

人员分布图

图 7-8描绘了一个设计良好、人员配备适当的项目的典型人员分配图。项目开始时是前端，在此期间核心团队正在进行系统和项目设计；此阶段结束时SDP 审查。如果项目在此时终止，人员配备将变为零，核心团队将可用于其他项目。如果项目获得批准，人员配备将初步增加，开发人员和其他资源将致力于项目中支持其他活动的最低级别活动。当这些活动可用时，项目可以吸收更多人员。在某个时候，您已经逐步投入了项目所需的所有资源，达到了人员配备的高峰。一段时间内，项目人员配备齐全。系统往往出现在此阶段的末尾。现在项目可以逐步淘汰资源，剩下的人员将致力于最依赖的活动。项目结束时，人员配备水平已达到系统测试和发布所需的水平。

Figure 7-8 depicts the typical staffing distribution chart of a well-designed and properly staffed project. At the start of the project is the front end, during which the core team is working on the system and project design; this phase ends with the SDP review. If the project is terminated at that point, the staffing goes to zero and the core team is available for other projects. If the project is approved, an initial ramp-up in staffing occurs in which developers and other resources are working on the lowest-level activities in the project that enable other activities. When those activities become available, the project can absorb additional staff. At some point you have phased in all the resources the project ever needs, reaching peak staffing. For a while, the project is fully staffed. The system tends to appear at the end of this phase. Now the project can phase out resources, and those left are working on the most dependent activities. The project concludes with the level of staffing required for system testing and release.

图 7-9展示了一个人员分配图，它演示了图 7-8的行为。要制作如图 7-9这样的图表，首先要为项目配备人员，然后按时间顺序列出所有感兴趣的日期（活动开始和结束的唯一日期）。然后，计算在感兴趣的日期之间的每个时间段内，每种资源类别需要多少资源。不要忘记在人员分配中包含那些没有特定活动但仍然需要的资源，比如核心团队、质量控制和编码活动之间的开发人员。这种堆积条形图在电子表格中很容易制作。本书附带的文件包含这些图表的几个示例项目和模板。

Figure 7-9 shows a staffing distribution chart that demonstrates the behavior of Figure 7-8. You produce a chart such as Figure 7-9 by first staffing the project, then listing all the dates of interest (unique dates when activities start and end) in chronological order. You then count how many resources are required for each category of resources in each time period between dates of interest. Do not forget to include in the staffing distribution resources that do not have specific activities but are nonetheless required, such as the core team, quality control, and developers between coding activities. This sort of stacking bar diagram is trivial to do in a spreadsheet. The files accompanying this book contain several example projects and templates for these charts.

由于感兴趣的日期可能不是均匀分布的，人员分布图中的条形图可能会在时间分辨率上有所不同。然而，在大多数规模适中的项目中，如果有足够多的活动，图表的整体形状应该遵循图7-8 .通过检查人员分配图，您可以快速获得有关项目设计质量的宝贵反馈。

Since the dates of interest may not be regularly spaced, the bars in the staffing distribution chart may vary in time resolution. However, in most decent-size projects with enough activities, the overall shape of the chart should follow that of Figure 7-8. By examining the staffing distribution chart, you get a quick and valuable feedback on the quality of your project design.

人员配置错误

人员分配图中可能会出现几个常见的项目人员配置错误。如果图表呈矩形，则意味着人员配置是固定的——这种做法我之前已经警告过。

Several common project staffing mistakes may be evident in the staffing distribution chart. If the chart looks rectangular, it implies constant staffing—a practice against which I have already cautioned.

人员分布图中间出现巨大峰值（如图 7-10所示）也是一个危险信号：这样的峰值始终表示浪费。

A staffing distribution with a huge peak in the middle of the chart (as shown in Figure 7-10) is also a red flag: Such a peak always indicates waste.

考虑一下，当您只使用人员很短的一段时间时，在招聘人员和培训他们了解领域、架构和技术方面所花费的精力。峰值通常是由于项目没有消耗足够的浮动时间而导致的，从而导致资源需求激增。如果项目用一些浮动时间换取资源，曲线就会更平滑。图 7-11描绘了一个人员配备达到峰值的示例项目。

Consider the effort expended in hiring people and training them on the domain, architecture, and technology when you use them for only a short period of time. A peak is usually caused by not consuming enough float in the project, resulting in a spike in resource demand. If the project were to trade some float for resources, the curve would be smoother. Figure 7-11 depicts a sample project with a peak in staffing.

人员分配图中的一条平线（如图 7-12所示）是另一个典型的错误。平线表示图 7-8中的高点不存在。该项目可能不重要，缺少资源来为原计划中的非关键活动配备人员。

A flat line in the staffing distribution chart (as shown in Figure 7-12) is yet another classic mistake. The flat line indicates the absence of the high plateau of Figure 7-8. The project is likely subcritical and is missing the resources to staff the noncritical activities of the original plan.

图 7-13显示了亚临界项目示例的人员配置分布。该项目在资源水平达到 11 或 12 时就进入亚临界状态。它不仅没有达到稳定水平，反而出现了低谷。

Figure 7-13 shows the staffing distribution for a sample subcritical project. This project goes subcritical at a level of 11 or 12 resources. It is not just missing the plateau, but has a valley instead.

不稳定的人员配置分布（如图 7-14所示）是另一个危险信号。在设计时考虑到这种弹性的项目注定会令人失望（见图7-15），因为人员配置永远不可能那么有弹性。大多数项目无法凭空变出人员，让他们立即投入生产，然后过一会儿再将他们解雇。此外，当人们不断从一个项目来来去去时，培训（或再培训）他们的成本非常高。在这种情况下，很难让人们承担责任或保留他们的知识。

Erratic staffing distributions (as in Figure 7-14) are yet another distress signal. Projects that are designed with this kind of elasticity in mind are due for a disappointment (see Figure 7-15) because staffing can never be that elastic. Most projects cannot conjure people out of thin air, have them be instantly productive, and then dispose of them a moment later. In addition, when people constantly come and go from a project, training (or retraining) them is very expensive. It is difficult to hold people accountable or retain their knowledge under such circumstances.

图 7-16显示了另一种需要避免的人员配置分布，即项目开始时的高人手增加。虽然这个图没有包含任何数字，但图表清楚地表明了这种一厢情愿的想法。没有一个团队可以立即从零人员配置达到峰值，让每个人都创造价值并提供高质量、值得生产的代码。即使项目最初有那么多并行工作，即使你拥有资源，下游网络也会限制项目实际上可以吸收的资源数量，所需的人员配置就会逐渐减少。

Figure 7-16 illustrates another staffing distribution to avoid, the high ramp-up coming into the project. While this figure does not include any numbers, the chart clearly indicates wishful thinking. No team can instantly go from zero to peak staffing and have everyone add value and deliver high-quality, production-worthy code. Even if the project initially has that much parallel work, and even if you have the resources, the network downstream throttles how many resources the project can actually absorb beyond that, and the required staffing fizzles out.

图 7-17展示了这样一个项目。该计划预计会立即达到 11 人，之后不久就会减少到 6 人左右，直到项目。任何团队都不可能以这种方式加快进度，而且由于团队规模过大，可用资源的利用效率很低。

Figure 7-17 demonstrates such a project. This plan expects instantaneously to get to 11 people, and shortly afterward deflates to around six people until the end of the project. It is improbable that any team can ramp up this way, and the available resources are used inefficiently due to the oversized team.

项目成本

Project Cost